Azure App Service and Azure SQL Database: Zero-Downtime Migration Interoperability

How the swap operation affects active Azure SQL Database connections

When an App Service slot swap executes, the source worker process (typically the slot being swapped from) stops. This stop action terminates the worker's in-process resources, including any open TCP connections that the application held to Azure SQL Database at the moment of shutdown. The receiving slot (the target) then starts with a fresh process that opens new connections using the same connection string.

Azure App Service does not implement a built-in graceful-drain for outbound SQL TCP connections during a swap. If the departing worker process recycles before in-flight requests complete, those requests may abort. The behavior depends on the App Service plan tier and whether Always On is enabled: Always On keeps the instance primed, but does not prevent connection termination at the moment of swap.

Warm‑up timeout and production slot safety

After a slot swap, traffic redirects to the new instance. If that instance is still warming up — initializing code, loading assemblies, establishing connection pools — and the front‑end load balancer or gateway health‑check timeout expires, the load balancer may mark the new instance unhealthy and route traffic away, creating a perceived outage. This is especially relevant when the staging slot has been scaled down or idle.

Mechanism to prevent this: ensure the staging slot is running and accepting connections before the final swap. This can be achieved by:

• Keeping Always On enabled on the staging slot so the worker remains active.
• Temporarily increasing the staging slot instance count so the new version is already handling requests.
• Using the slot swap with preview feature, which validates the target slot’s health check response before committing the traffic redirect.

If the staging warm‑up period routinely exceeds the default front‑end timeout, the recommended step is to pre-warm the slot using one of the above methods before initiating the final swap.

Verification steps (safe, scoped)

1. Before swapping, query existing connections: SELECT session_id, client_net_address, login_name FROM sys.dm_exec_connections WHERE database_id = DB_ID(N'YourDatabase');
2. After swap, repeat the query to confirm whether connections were preserved or dropped.
3. In Azure Monitor, observe Total Swaps and Process Restart Count metrics for the affected slot.
4. Use the slot swap preview endpoint via CLI or portal to validate health check passage before committing.

Missing diagnostic detail: What is the App Service plan tier and Always On status for the slots in question? This determines whether the staging instance remains warm enough to avoid front‑end timeouts, and whether connection pooling behavior aligns with the observed swap timeline.