Migrating a DNN website to the Cloud Part 6
Lessons Learnt
Although the whole process went relatively smoothly and finished within the expected timeframe, not everything went to plan and, while the two unexpected issues were relatively minor and easy to remedy, it is worthwhile to document them just in case you encounter similar problems in your migration.
Problem 1 – SQL migration error
All the files necessary had copied without error to the new App Service website in Azure and it appeared that the SQL data migration had also completed successfully but the website itself would not start throwing a nasty exception that seemed to be related to some sort of database error.
After checking the obvious thing such as the connection string in the web.config file was actually correct, I inspected the SQL Migration tool’s logs. Oddly enough, there were two errors near the end indicating that the bulk copy into one of the DNN tables had failed. On inspection it was determined that the table – dbo.files - did not even exist. Checking the export SQL script indicated that the dbo.files table should have been created so I assume that some sort of unexpected network error had occurred.
As it was only one table, it seemed reasonable to recreate it and just bulk import the data manually rather than redoing the entire migration. So, a connection to the old hosted version of SQL was made and the offending table was exported to a script using SQL Management studio. This can be done by right clicking the table and selecting Script Table As – Create To – New Query Editor Window.
After inspecting the table script, nothing was found that would indicate any incompatibilities with Azure so, after disconnecting from the original SQL server, a connection was made to the Azure SQL server and the script was run to create the missing table.
Then, from a command prompt on the local computer used for the migration, the bcp tool was used to bulk import the missing data that had been exported from the source SQL server by the SQL Migration Tool into the table that had just been created. The command used is shown below:
bcp [databasename].[dbo].[Files] in "c:\SQLAzureMW\BCPData\dbo.Files.dat" -E -n -C RAW -b 1000 -a 4096 -U databaseuser -S databasename.database.windows.net -P password
Substitute your database name, user name and password.
As there were only 7000 or so records in that table, the process took very little time. After that the Azure version of the website started correctly.
Problem 2 – Error handling
Quite how I managed to miss this rather obvious one is a bit of a mystery but, during testing of the Azure version of the website, it became clear that the error handling was not working as expected. The 404 error page for missing pages had been migrated correctly and could be called directly but I, in the case of a genuinely missing page, the expected 404 page did not display with a generic error appearing instead.
Fortunately this proved to a simple problem to resolve. Inspecting the web.config file once more, in the HTTPErrors section were entries for the custom http error pages.
error statusCode="400" path="C:\inetpub\vhosts\oldserver.com\error_docs\bad_request.html" />
On the old server, these pages had been specified using their physical path. As there is no C drive on the Azure version, the error handling would now throw an error itself. The resolution was simple – double check that the files had been copied over and replace the entries for the physical paths with the relative paths instead.
Always test what happens when things don’t work as well as what happens when things do work.
Job done and lessons learnt – time for a nice cup of tea!