Slower After the Azure Migration? How to Narrow Down the Cause

The quickest way in: classify an observation

What are you observing? Choose the matching card; it leads to the first step.

The observation determines where you start. It does not yet establish a cause.

Step 1: Name the slow work precisely

Choose one specific operation: saving an order, opening a list or running a particular import. Note the start, the end, the application involved and the business inputs. “The database is slow” is too vague to work with.

Next, clarify which time was measured. The response time in the application can include connection setup, several database calls, result transfer and further processing. The runtime of a SQL statement describes a different portion of that time.

If an operation executes many database calls one after another, its response time can rise while the individual SQL calls stay about as fast. Conversely, a single expensive query can account for most of the time.

Record three values separately: the response time of the whole operation, the number of its database calls and the times measured on the database side. Overlapping or asynchronous work must be taken into account when assigning the times.

A measured difference between application time and statement time is not automatically pure network latency. Processing in the application, waiting for a connection or other services can contribute as well.

Step 2: Establish a fair comparison

A before/after comparison helps only if the work being compared is sufficiently similar. Therefore check:

• Data and inputs: the same business task, a comparable data volume and relevant parameter values.
• Load: calls per unit of time, work mix and concurrent processing.
• Configuration: source and target, version or service model, compatibility level and important settings.
• Time window: a common time base for application, SQL data and Azure metrics; changes and events with timestamps.
• Operating state: regular operation, first run after a restart or pause, ongoing maintenance and other special events.

Additionally compare the number of successful completions and the errors. A low measured utilization can also arise when many requests fail beforehand or wait on the application side.

If the old baseline is missing

Preserve the data that is still available and write down what it can answer. Existing Query Store history, application logs or earlier operations reports can help. How informative they are depends on the period covered, how the data was collected and how comparable it is.

Missing data cannot be created retroactively. However, you can compare a period that is slow today with one that is unremarkable today, or check the same operation in a controlled way before and after a change. The finding then reads “improved under these current conditions.” That does not yet prove a complete explanation of the original migration difference.

Step 3: Consider the resources in the right frame

An Azure SQL environment has several possible performance limits. CPU is one of them. Data access, log throughput, memory or available execution capacity can also limit processing.

What matters is the frame of reference: A percentage metric refers to the resource and limit named in its definition. The utilization of a database does not automatically describe the utilization of the physical Azure hardware.

In Hyperscale, the data IO metric refers only to the local cache of the compute replica. Page accesses to the page servers do not appear there; Microsoft reports them in separate columns of DMVs, in the Query Store runtime statistics and in the execution plan. Throttled log generation shows up in wait types of the group RBIO_RG_*. A low data IO value therefore does not rule out slow data access in Hyperscale.

Pay attention to short peaks and to the aggregation of the metric. A smoothed average over a long period can hide a brief bottleneck. Therefore read CPU, IO or waits in the same problem window as the slow operations.

For write load, separating data IO from the transaction log is worthwhile. A bottleneck in the log path can slow down save or import operations while the CPU still has headroom. The appropriate next step follows from the combination of platform metrics, SQL wait behavior and affected operations.

Sources: Microsoft’s baseline recommendation for Azure VMs, MI monitoring and resource management in elastic pools; for Hyperscale, the performance diagnostics for Hyperscale.

Step 4: Check queries and mutual interference

Does the same work use more CPU, more logical reads or longer database runtimes after the switch? Or does more work arrive at the same time? These questions help separate causes from effects.

Use Query Store to trace a change

Query Store can show which queries and plans were captured in a period and how their aggregated runtime values have changed. First check whether the required history is available and whether the data capture is suitable for your question.

For executions that belong together in business terms, compare:

• execution count and work mix;
• CPU work and logical reads per execution;
• database runtime and, where captured, wait categories;
• plans used and the point in time of a change.

A new plan is a reason to investigate. Whether it explains the degradation becomes clear only through comparison with matching data, parameters and load conditions. Statistics and configuration changes also belong in this check.

Query Store aggregates runtime data in runtime statistics intervals. It is not a complete log of every user call. From an interval average, you can derive neither the exact course of an individual application error nor a correct 95th percentile of all user responses. For such questions you need suitable supplementary application or individual-event data.

If you combine values across several intervals, take their different execution counts into account. Simply averaging the interval averages can distort the result. When comparing separate systems, match queries by content and context; the numeric query and plan IDs alone are not a reliable identity across systems.

Source: Monitor performance by using the Query Store.

Investigate blocking and transactions

Operations can obstruct each other through locks in Azure as well. In the problem window, check who is waiting, which operation holds the required resource and how long the transaction in question stays open.

A slow transaction can trigger waiting in many other operations. High utilization is not a prerequisite for this. For example, the application may perform further work within a transaction or wait for the next interaction.

Waits help put things in context. Because of parallel and overlapping work, they are not consistently additive pieces of user response time. A large wait sum is therefore not the same as an equal number of seconds of additional waiting for an individual user.

For general diagnostic paths, we refer to our SQL Server performance guide. The measurement sources and permissions must each match the Azure platform.

Step 5: Check network paths, startup state and error recovery

Many small calls can multiply additional time

If the application stays at its previous location and the database moves, the communication path changes. For one large database call, this may be less noticeable than for a sequence of many small calls.

Illustrative calculation: An operation executes 100 database round trips serially. If each round trip takes an additional 10 milliseconds because of the changed path, this adds up to roughly one second of additional time in total. The calculation assumes these serial calls and the assumed additional round-trip time; it is not an Azure measurement and not a prediction for your application.

Check the actual number and sequence of calls. Possible starting points are where the application is placed, batching data access and avoiding unnecessary repetition. Whether such a change fits functionally and technically must be verified against the specific workflow.

Source: Microsoft’s tuning guidance for applications that communicate frequently.

Look at the first operation after an idle period separately

If the environment uses serverless, check the configured scaling and, where applicable, the auto-pause and auto-resume behavior. An automatically paused database needs time when it resumes. Warm-up of the environment can also affect the first operations.

Therefore separate the first connection after an idle period from regular operation. Check status events, connection attempts and the requirements of the application. Auto-pause is not available for every serverless configuration or in combination with other features; for Hyperscale serverless, it is in preview as of 27 October 2026.

In Hyperscale, the local cache comes into play. With provisioned compute, Microsoft keeps the cache of the high-availability replicas warmed up; with serverless, it does not. After a restart or a replica switch, the first read accesses may therefore go to the page servers more often.

Source: Serverless FAQ from Microsoft.

Make retries visible

An application can catch a transient connection fault and try to execute the operation again. From the user’s perspective, this may appear only as a longer response time. Without suitable logging, the retries remain invisible.

Check which errors occur, whether connections are re-established and how many attempts take place. Retries need suitable limits and must be matched to the error. For write operations, it must also be clarified whether the previous transaction already took effect and how duplicate processing can be prevented.

A higher timeout value alone does not explain the cause. It initially changes only how long an application waits for a result.

Source: Transient connection faults and retry logic.

Step 6: Justify a change and verify its effect

Before the change, formulate a concrete expectation. For example: “After the index change, this query needs fewer logical reads” or “Batching the calls shortens the affected application operation under the same load.”

Next, define how the expectation will be verified. Use the same business operations and sufficiently similar conditions. Compare response time, successful completions, errors and the relevant resource demand. For critical processes, also take the remaining workload into account: A change should not speed up just one individual test while slowing down other important operations at the same time.

A larger configuration can help as an immediate action or as a limited comparison. If it improves the situation, an effect has initially been observed under the tested conditions. Which resource and which mechanism explain the improvement must be narrowed down further.

Next, evaluate the economic consequence. With fixed provisioned capacity, a more efficient query lowers the bill only when it leads to, for example, a suitably smaller configuration. For usage-based models, their specific billing rules apply. A measured technical improvement and a demonstrated change in cost are two separate results.

Your findings sheet for the next check

With these details, “slow since Azure” becomes an investigation that can be worked on.

For an initial inquiry, the available key data is sufficient. Production credentials and complete SQL or business data do not belong in the contact form; we will agree on a suitable analysis access separately.

Frequently asked questions

Sources and limits

The figures on this page are structural models and teaching examples. They contain no measured values from Azure environments or customer systems; the round-trip calculation rests solely on the stated assumptions.

Product limits change over time; this page reflects the status of 27 October 2026. It is based on public Microsoft documentation; it is not based on our own measurements in Azure environments. For a specific decision, check the information that is current at that time.

Sources from Microsoft (documentation reviewed on 27 October 2026): Baseline for SQL Server on Azure VMs · Monitor Managed Instance with Azure Monitor · Resource management in elastic pools · Monitor performance by using the Query Store · Tuning guidance for Azure SQL Database · Serverless FAQ · Transient connection faults and retry logic · Performance diagnostics for Hyperscale

Further reading