Upgrade projects running on Windows Azure

For more information, see Deploy projects to Microsoft Azure.

PREREQUISITES: During the upgrade, you must temporarily decrease your role instance count to a single instance.

1. In Sitefinity CMS Project Manager, select the project that is currently deployed to your Microsoft Azure production environment.

   NOTE: If the project you want to upgrade is not in the list of projects of the project manager, you must add it. For more information, see Work with Sitefinity CMS Project Manager.

2. Upgrade the project locally, to replace the old .NET assemblies with the new ones.
   For more information, see Upgrade.

   RECOMMENDATION: Because this project is configured to connect to your production Azure SQL database and using it locally, you can modify it, we recommend either to avoid using it locally, or to temporarily change the database connection string.

3. Create a deployment package with no changes to the configuration.
   It must point to the same production database and storage account, but you must configure it for a single role instance.
4. Stop your production environment.
   You must do this, because deploying Sitefinity CMS to the staging environment attempts to upgrade the production database. In case of failure, it will be restored from a backup copy, which will become outdated, if the production environment is left online and a user activity causes changes to the data.

   NOTE: If you have other means to ensure no data is changed or the changes after the backup can be discarded in case of failure and database restore, you can leave the production environment online.

5. Create a backup copy of your Azure SQL database.
   For more information, see Copying Databases in Azure SQL.
   1. Because copying databases in Azure SQL is done with a special purpose SQL statement, you must log to an environment that allows you to execute an SQL script against the master database of your Azure SQL server.

      For this purpose, you can use Microsoft SQL Server Management Studio 2008 R2 or use an instance of database manager co-located in every Azure SQL datacenter. You can launch it from the Management Portal » Databases » <Your Subscription> » <Your Server> » master  » Manage.

      NOTE: In both cases, you must login to the master database, because this is a requirement for the special purpose statement.

   2. Execute the following SQL statement:

      CREATE DATABASE <copy> AS COPY OF <original>

      Replace <copy> with the name of the backup copy database and <original> with the production database’s name.
      The above statement only initiates the copying process.

   3. To monitor the state of the operation, execute the following SQL query:

      SELECT name, state_desc FROM sys.databases

      Execute the statement as many times as needed, until you see that the <copy> database is in ONLINE state.

      NOTE: The new database created from the copy process is transactionally consistent with the source database at the point in time when the copy completes. This means, that the role instances, which are running against this database, do not have to be stopped. However, if, for whatever reason, a data loss is experienced during the upgrade of the production database, the copy that will be restored will not have the data that was stored in the source database, after the copying process is complete. For this reason, you may prefer to plan some downtime during the upgrade.

6. In the Management Portal, select your hosted service, choose the New Staging Deployment, and specify the location of your new deployment package and configuration.

   RECOMMENDATION: The new Sitefinity CMS deployment will perform an online upgrade of the live production database on the first request to the application. We recommend you to request the site to force the upgrade and ensure there are no problems with the upgrade.

7. After the upgrade completes successfully, perform the following:
   1. Select your hosted service in the Management Portal and click the Swap VIP button from the ribbon.
      This effectively swaps the production and the staging environments. Because they both point to the same database and the locally upgraded staging environment has already upgraded the database, it is safe to make it your production environment.
   2. Increase the instance count to whatever value is needed for production usage.
      To do this, select the production deployment in the Management Portal and click the Configure button. Instead of uploading a new configuration file, edit the configuration and change the count in the following element:

      <Instances count="3" />

      NOTE: Microsoft Azure creates and starts new instances to satisfy the required count. This is a time consuming process. During this time, the single instance is still available.

   3. Keep the staging environment as long as you find it feasible, then stop and delete it.
      This staging environment was your former production environment.

      The same applies for the database copy.

1. Stop all instances of the production deployment.
2. Rename the live production database that failed to upgrade to another name, using the following SQL statement:

   ALTER DATABASE <old_name> MODIFY NAME = <new_name>

3. Using the same technique, rename the backup database to the name of the original database.
4. Start all instances.
5. Stop and delete the failed staging deployment.
6. Delete the copy of the production database that failed to upgrade or download it and contact the support.

   NOTE: To download an Azure SQL database,  see Export an Azure SQL database to a BACPAC file.