I'm planning to push a new web application to an Azure Web App Service (former Azure Website). I'd like to make use of the deployment slots to be able to test my deployment before pushing it to production. That's all fine as long as there is no DB schema change require. But if there is a schema change I can't have two software versions operating on the same db version. Since I'm using EF Migrations, the push to the staging slot would instantly result in a DB update to the latest version.

So my question is, whether there is any use of deployment slots when a db migration is required?

How is it done for large SaaS providers. Are they performing a DB migration instantly with the new version? That would surely cause some downtime.

I can only think of rather complex solutions to this problem, is there anything simple?

  • So you don't have a dev database? – JeffO Apr 1 '15 at 18:04
  • Yes, we have a dev and QA system. The system described above is for production purposes. – Sam7 Apr 1 '15 at 22:21
  • @Sam7 did you manage to find a solution to this issue? Cheers – WestDiscGolf Apr 27 '15 at 9:09
  • I'm afraid not. We're currently testing migration changes in a separate environment. – Sam7 Apr 28 '15 at 4:22
  • @Sam7: i think you can manage this by a separated .config-file with an own connection string to your db. but you are right, when you deploy from stage to production, the benefit of a rollback doesn't work anymore. the db changes will apply instantly. i'm curious for a solution in the near future... – Roger S. Oct 13 '15 at 12:23

Zero-downtime releases using Azure App Service slots and a single database shared by Staging and Production are possible - but you need to make sure that all database changes are backwards compatible, such that the current and new versions of the web app can run simultaneously in the Staging and production slots.

Some rules that ensure this works:

  • Any new database columns should be nullable or have default values
  • Renaming columns is not permitted
  • Dropping columns is not permitted

When you do need to make destructive changes, such as renaming or dropping columns, you need 2 releases to do this:

  1. The new version of the web app should be released, which removes the dependency on the renamed/dropped columns
  2. An additional release is made that performs the destructive changes

While this sounds a bit complicated, in practice you likely won't be making destructive changes very often.


have you looked at the slot-specific configuration items? Under WebApp/Settings/Application Settings you can specify settings for the web app but also define whether it only applies to this slot.

You could, therefore, have a slot-specific connection string for your staging slot and apply the migration on swapping slots too.

  • 2
    That goes against my idea of having the staging site working off the exact same dataset (-> database) as production. – Sam7 May 12 '16 at 6:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.