Migrating a DNN (Dotnetnuke) site to the Cloud Part 1

Scenario

A Dotnetnuke (aka DNN or Evoq) website with 2 portals is to be migrated from shared website package to Azure cloud hosting. The portal runs v9.0.2 of the DNN CMS. The portal will be migrated to Azure app service package hosting with a separate SQL database which will also be hosted in Azure.

Investigation

Initial investigation determined that the SQL database was hosted on a shared instance of SQL 2012 Express which will limit performance and thus extend the time necessary to complete the migration. The DNN instance was originally created in DNN 4.5.2 and has been upgraded in place many times up to the current version so there are likely to be legacy issues. It is usually a good idea to upgrade your DNN installation and all its modules prior to migration. Both portals within the DNN instance are live but a change freeze can be implemented on both of them. Evotiva DNNbackup v8 software is the backup solution for the DNN instance.

The process to migrate to Azure is non-destructive in that the original site will still be available to use as a roll back if something unforeseen happens. This will also allow the functionality of the site to be tested after it has been migrated but before it is put into production. The final step in the migration process will therefore be changing the appropriate DNS records to point at the instance in Azure rather than the one on shared storage.

Data Sizing

• Approximate SQL database size: 160Mb
• Approximate file system size (images, JavaScript, stylesheets, CMS files): 800 Mb

Summary of Tasks

• Verify that a SQL backup is available
• Verify that a full file backup off the DNN instance is available
• Verify that the SQL database is compatible with Azure version of SQL
• Remove unused modules from the DNN instance
• Delete obsolete files from the DNN instance if possible
• Create an account in Azure to set up hosting
• Verify access to DNS zone for each of the two portals
• Migrate DNN instance to Azure
• Test DNN instance
• Change DNS settings

Verify that a SQL backup is available and verify the full file backup

As there are several ways to migrate a DNN instance to Azure, it will be necessary to do some testing to find the most appropriate method. To aid in the determination of the best method, a virtual machine running Windows 2012 and SQL 2012 Express was created in a test environment. The database and file backups were restored using the Evotiva restore wizard. However, it should be noted that the version of SQL in Azure does not support BAK files but doies support BACPAC and DACPAC files.

Verify the SQL database is compatible with the Azure version of SQL

As we now have a test environment, the next step wass to verify that the SQL database is compatible with Azure. The DNN version (v9.02) is compatible, on paper at least, but there was the possibility that some of the third party modules used within the three portals may not be. If that proves to be the case, then these modules will have to be upgraded, modified (if possible) or removed.

There are a number of ways to check the compatibility but, for this particular case, we will be using the SQL Database Migration Wizard available as free download from Codeplex (https://sqlazuremw.codeplex.com/). This can generate scripts for the migration and will highlight any incompatibilities. As the primary interest at this stage is compatibility, this first run will be used to identify any potential problems therefore only the database schema needs to be checked.

As there is no administrative access to the source server, a decision was taken to clone the DNN instance using Evotiva DNNBackup to a local Virtual machine. Although the SQL database Migration Wizard works perfectly well remotely – if you have access to the SQL installation, that is - it will take some considerable time to complete (in this case, testing that very scenario took nearly 3 hours just for the schema check). Using a cloned installation will also allow any corrective actions to be tested prior to being applied to the production instance.

The Results

Analysing the resulting log file produced the first surprise. “Not for Replication” had been set on almost all the tables in the database used by the DNN instance. “Not for replication” is incompatible with SQL Azure and, with a bit of research, it would appear that setting has not been used in DNN since v6.x. It is possible that this setting has existed since the DNN instance was created and was not removed by subsequent upgrades or it was a side effect of the database being hosted on a SQL Express instance.

 Two tables were found that belonging to modules that were no longer used. It is good practice however to double check this. Using SQL Server Management studio, check the dependencies for these now superfluous tables.

In the example above, three stored procedures are as shown dependent on the table so these would be deleted first and then the table would be deleted.

There were a few tables missing the clustered index on the primary key needed by Azure. A clustered index would need to be created for each of these tables unless the modules could be removed. Curiously, two of these tables were used by standard DNN modules (the Links and Announcements modules) and their versions were current. However, neither module was in use so the decision was taken to remove them.

A stored procedure using a SELECT INTO statement was also detected. In this case, the module using that stored procedure was not actually in use so the module would be removed. If the module was actually in use, the stored procedure would need to be rewritten using CREATE TABLE and INSERT INTO statements.

In Part 2, we shall configure the Azure App Service for the migration.