Context
A staging slot works perfectly, but the promoted application cannot read its secrets or connects to the wrong database. The code did not necessarily fail. Deployment slots have their own configuration and identity behaviour, and a swap changes some properties while others remain associated with a slot. Safe promotion requires an explicit map of what moves, what stays, and what the application reads during warm-up.
Treat a slot as a running environment
Microsoft documents deployment slots as live applications with their own hostnames. The App Service swap guidance lists settings that swap and settings that do not, including managed identities. App settings and connection strings can also be marked as deployment-slot settings. Review the current rules for your App Service configuration rather than assuming that a slot is just a named copy of production code.
Create a table listing each important setting, its current value reference, whether it is slot-specific, and the service it affects. Include database addresses, secret references, queue names, storage locations, feature flags, and external callbacks. Record references and identifiers rather than exporting plaintext secrets into the change document.
An illustrative secret-access failure
Imagine a staging application using its own managed identity to read a test secret. Production uses a different identity with access to the live secret. After a swap, the new code reads configuration that does not match the identity still associated with the destination slot. The application starts but fails its first protected dependency call.
Diagnose the effective runtime identity and secret reference at the destination. Do not grant access to every identity simply because the problem appeared during promotion. Establish which identity is intended to access which resource, then repair the configuration or permission at that boundary. A broad access grant can make the symptom disappear while leaving the environment separation wrong.
Design the warm-up path
The swap process prepares the application before routing production traffic. Review which configuration and dependencies the warm-up stage sees in your selected workflow. A health endpoint that only returns a fixed string may hide a broken dependency, while a warm-up action that sends emails or processes payments can create real side effects.
Make readiness checks representative and safe. They can confirm that essential configuration is readable and a required dependency is reachable without creating customer transactions. Keep destructive maintenance and queue consumption out of a generic startup path unless the architecture explicitly handles overlapping application instances.
Protect background work from overlap
During preparation, more than one application instance or slot may be alive. Scheduled jobs, queue consumers, and startup migrations need an ownership strategy. A web routing swap does not automatically guarantee that only the intended background worker is active.
Use environment-specific destinations or a durable coordination mechanism where appropriate. Verify that staging cannot consume production work merely because it temporarily sees a production-related setting. Record which processes run in each slot before, during, and after the swap. This inventory often exposes risks that a browser-only staging test misses.
Check database compatibility independently
A slot swap changes application deployment state; it does not reverse a database migration. Ensure both the current and new application versions can operate safely during the transition where required. Review destructive schema changes, renamed fields, and background data migrations before selecting a rollback strategy.
Prefer a staged compatibility plan when releases share a database: introduce compatible structures, deploy code that understands the transition, migrate data deliberately, and remove obsolete structures later. The exact sequence depends on the application. The important point is to make rollback assumptions explicit rather than promising that swapping back reverses every effect.
Rehearse with observable identity
Expose a suitable internal diagnostic that identifies application version, slot context, and non-sensitive dependency references. Use it to verify the destination after promotion. A response from the expected hostname is insufficient if a cached page or old process can answer the check.
Run a complete rehearsal using production-like identity boundaries and slot-specific settings. Test secret access, database connection, storage operations, callbacks, and any background processing that belongs in scope. Keep a result for each dependency so the release owner can review a concrete acceptance record.
Define abort and recovery decisions
Before promotion, state what stops the swap and what triggers a swap-back decision. Include a time budget for observing startup errors and a clear owner for database-related concerns. If new code has already changed external state, recovery may require reconciliation in addition to routing traffic.
Preserve logs and effective configuration references when a failure occurs. Repeated rapid swaps can obscure which version and setting combination produced the error. Stabilise the environment, identify the failed boundary, and verify the proposed correction in a controlled sequence.
Quick diagnostic map
| Evidence | Interpretation | Next check |
|---|---|---|
| Promoted secret read fails | Identity and reference disagree | Inspect destination context |
| Staging processes live work | Consumer ownership unclear | Review slot destinations |
| Swap-back breaks schema | Durable compatibility gap | Inspect migration state |
A focused operator exercise
Build a slot matrix containing code revision, effective identity, database reference, secret reference, queue destination, and background-process ownership. Review which values move during the selected swap workflow and which remain associated with the slot. Use non-sensitive references so the matrix can be retained with the release receipt without exporting credentials.
Rehearse promotion with an internal diagnostic that exposes the deployed revision and permitted environment identifiers. Verify secret access and a representative database operation at the destination. Observe scheduled jobs and consumers while both slots are alive. Any work that reaches an unintended production destination should stop the exercise until its ownership model is corrected.
Then rehearse the documented recovery path after a controlled acceptance failure. Confirm whether swapping back is sufficient or whether a durable effect needs reconciliation. Keep schema compatibility and external actions in that decision. The exercise passes when operators can explain the code, configuration, identity, and background-work context at every stage without granting broad access to make the new release start.
Maintain the configuration contract
Update the slot-setting table whenever a new dependency or identity is introduced. A small new environment variable can change the safety of a previously reliable release procedure. Include the setting's intended swap behaviour in code review and deployment documentation.
Clouvenix can help review the slot map, managed identities, warm-up checks, and compatibility plan together. The objective is a promotion whose runtime context is understood before users reach it and whose recovery path matches the application's durable effects.
Explore Clouvenix devops automation for implementation and operational handover.