Azure App Service deployment slots: ship a release with a verifiable swap

Treat the slot as a running environment

An App Service deployment slot is a live application with its own hostname. It gives you a place to deploy and validate a candidate release before directing production traffic to it. Slots are available on supported App Service plan tiers, including Standard, Premium and Isolated; verify the limits of the selected plan before making them part of the release process.

A staging slot is not automatically isolated from production data or external effects. It can run startup tasks, scheduled code and queue consumers if its configuration enables them. Decide which dependencies and background activities belong in staging. Use representative test data or explicitly controlled production connectivity rather than assuming that a different hostname creates a complete environment boundary.

Review which settings should stay with the slot

Slot swaps move some application content and configuration while other settings remain attached to their slots. Review Microsoft's current swap behavior and mark applicable application settings or connection strings as deployment-slot settings when they identify a specific environment. Build a small configuration inventory that names each dependency and its intended swap behavior.

Managed identities and several network or platform settings have their own slot behavior. Validate the identity and access path of each slot directly. A staging release can succeed with one principal and then encounter an authorization failure under production configuration. Database endpoints, vault references and external webhook destinations deserve explicit attention.

Run a release sequence that produces evidence

1. Deploy an immutable release artifact to the staging slot.
2. Verify its configuration and disable unintended background effects.
3. Run startup, readiness and representative user-flow checks on the slot hostname.
4. Review the slot-specific setting inventory before requesting the swap.
5. Verify production requests, dependencies and telemetry after traffic changes.

Warm-up checks should exercise the path the application needs to serve requests, not only a static landing page. Use a bounded readiness response and a small representative request that validates essential dependencies. Keep the health response free of secret values, detailed connection strings and infrastructure credentials.

Keep database changes compatible with both releases

A slot swap changes which application release receives traffic; it does not undo database writes or reverse a schema migration. During the transition, design schema changes so both the current release and candidate release can operate. Expand and migrate before removing a field that the previous version still requires. Test the recovery sequence as part of the release rehearsal.

Do not interpret a successful platform swap as proof that checkout, sign-in or a background processor is working. Check actual request outcomes and failure rates after the swap. For an error, distinguish startup health, identity permissions and application behavior. Preserve enough release metadata to identify the running artifact unambiguously.

Make rollback a tested application operation

Retain the previous release while the new version is observed. If switching traffic back is appropriate, verify that its configuration and schema assumptions still hold. Document any irreversible data operation separately. Deployment slots shorten the traffic transition, while compatible releases and explicit verification make the overall deployment dependable.

References

• Set Up Staging Environments - Azure App Service — Microsoft Learn
• Monitor the Health of App Service Instances - — Microsoft Learn