Stopping production deployment during upgrade in azure - On Premise – Configurations & Setup - On Premise – Configurations & Setup - Progress Community
 On Premise – Configurations & Setup

Stopping production deployment during upgrade in azure

  • Stopping production deployment during upgrade in azure
  • Hi guys,

    During the upgrade process on azure your documentation ( says to stop the production environment.

    I'm assuming this would cause a total outage (regardless of how many instances we have running).

    For public facing sites I'm assuming the user would get a 404 or 500 error or something. Could we just drop the app_offline.htm file into the web deployment or something to bring up a maintenance screen during the upgrade or would we have to maybe repoint the DNS to another site with something like this during the upgrade. I'm looking for ideas to minimize downtime for users. I'm all for a maintenance screen but having a user get a HTTP error, not so much.


  • Hi Bil,

    If you are using Azure cloud service you can check the following link:

    How to Manage Cloud Services

    The idea is that you can upgrade your production project locally and then deploy it on staging. When you are sure that the project is running without any problems you can swap staging with production as it is outlined in the article above.

    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Sitefinity CMS Ideas&Feedback Portal and vote to affect the priority of the items
  • Hi Kaloyan,

    Thanks. I tried this out and the swap works well. There was a brief outage (yellow screen of death) and a delay as the deployments were being swapped but I think if I up the instance to 2 that might be avoided.

    I think the issue with Sitefinity is that the same database is tied to both deployments so I would imagine this isn't going to work well on an upgrade or if you have content changes dependant on your new code changes (for example a page using a new widget). That page would break on the old prod deployment until the swap happened.

    Otherwise it works and seems to be pretty clean.