Deployment slot settings copied during swap and not restored after revert

Question

Deployment slot settings copied during swap and not restored after revert

Vitor Leitao 5

We’ve hit a strange issue with Azure Web App deployment slots.

2 Web Apps were set up with Environment Variables marked as “Deployment slot setting.”

When performing a swap (Staging → Production), instead of staying in their respective slots, all Staging Environment Variables were copied to Production, and Production settings were moved into Staging.
When we attempted another swap to roll back, one of the apps correctly restored Production’s original configuration, but the other app ended up with both slots using the Staging configuration.

This is unexpected because slot-specific settings should stay pinned to their respective slot during a swap. We’ve done many swaps on these apps before and never hit this.

Questions:

Is this a known bug or regression in slot-swap behavior?

Is there any official documentation describing scenarios where slot-specific settings can still be swapped or overridden?

Bhargavi Naragani 7,690 Reputation points Microsoft External Staff Moderator

2025-08-26T13:07:51.4966667+00:00
Hi Vitor Leitao,

From what you described, one app behaved correctly after swap and revert, while the other ended up with both slots showing Staging’s configuration. This usually happens if:

Some environment variables were not consistently marked as sticky in both slots.

A setting existed in only one slot (not both). Azure only compares and preserves settings that exist in both slots.

During swap, there can be transient timing issues as both apps restart and warm up, briefly showing unexpected values.

Double-check slot configuration: Go to Configuration => Application settings for both Production and Staging slots, ensure every variable that should stay pinned is consistently marked as Deployment slot setting in both slots.

Use Swap with Preview: This lets you validate which settings will move and which will stay before completing the swap. https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?utm_source=chatgpt.com&tabs=portal#swap-with-preview-multiple-phase-swap

Keep settings aligned across slots:

Even sticky settings should exist in both slots for predictability.

If a variable only exists in Staging, swap results can be inconsistent.

The setting WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS can be used if you need to override how stickiness is preserved globally. https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?tabs=portal#-steps-for-making-a-slot-unswappable

Hope this helps, if you have any further concerns or queries, please feel free to reach out to us.
Scott Juranek 0 Reputation points

2025-08-28T21:50:07.08+00:00

I just ran into this as well. Sometime around Aug 26-27. I do tons of swaps and all the sudden production got the "Staging" environment variable and wasn't running background jobs. something seems to have changed to cause this.

1 answer

Your answer

Bhargavi Naragani 7,690 Reputation points Microsoft External Staff Moderator

2025-08-26T13:07:51.4966667+00:00

Hi Vitor Leitao,

From what you described, one app behaved correctly after swap and revert, while the other ended up with both slots showing Staging’s configuration. This usually happens if:

Some environment variables were not consistently marked as sticky in both slots.

A setting existed in only one slot (not both). Azure only compares and preserves settings that exist in both slots.

During swap, there can be transient timing issues as both apps restart and warm up, briefly showing unexpected values.

Double-check slot configuration: Go to Configuration => Application settings for both Production and Staging slots, ensure every variable that should stay pinned is consistently marked as Deployment slot setting in both slots.

Use Swap with Preview: This lets you validate which settings will move and which will stay before completing the swap. https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?utm_source=chatgpt.com&tabs=portal#swap-with-preview-multiple-phase-swap

Keep settings aligned across slots:

Even sticky settings should exist in both slots for predictability.

If a variable only exists in Staging, swap results can be inconsistent.

The setting WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS can be used if you need to override how stickiness is preserved globally. https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots?tabs=portal#-steps-for-making-a-slot-unswappable

Hope this helps, if you have any further concerns or queries, please feel free to reach out to us.
Scott Juranek 0 Reputation points

2025-08-28T21:50:07.08+00:00

I just ran into this as well. Sometime around Aug 26-27. I do tons of swaps and all the sudden production got the "Staging" environment variable and wasn't running background jobs. something seems to have changed to cause this.

Answer 1

Hi @Bhargavi Naragani

Has this behaviour changed? We've done hundreds of these swaps over the years and settings marked as Deployment slot setting never copied over before. I can assure you at 100% that the settings that are being copied have not changed in multiple releases and some have not changed in years.

From my point of view, the settings pinned in either side with Deployment slot setting (in our case it was pinned in both sides) should never be moved over between slots.

Is this a behaviour change from Azure, a bug?

Kind Regards,

Vitor Leitao

Share via

Deployment slot settings copied during swap and not restored after revert

1 answer

Your answer