- Dan Lister
Migrating an Umbraco site to Windows Azure is a pretty painless experience. You don't really need to use any other tools or services other than Windows Azure Websites and Bitbucket or Github. We've found that you should be able to run any version of Umbraco without facing any problems. We've tried and tested running version 4.11, up to the latest version 6.1.5. We've outlined a couple of caveats for you to be aware of too. If you have a local Umbraco instance, then the following steps might be useful to migrate an existing site.
Add a clustered index to the User Logins table
You can find more information about this step on Code Cloudy's site. SQL Azure doesn't like tables without clustered indexes. We think this has something to do with being unable to replicate/distribute tables without indexes.
Move the database via SQL Server Management Studio
If you have an existing SQL Azure server instance then you can use the 'Export Data-tier application' option via SQL Server Management Studio 2012 to create a local backup of the database.
Once backed up, connect to the SQL Azure server instance and use the 'Import Data-tier application' option. This will add the new database to the SQL Azure instance. It's as painless as entering the server location, specifying a new database name and clicking export.
Create a new website in Azure
A new, quick website will do. You might want to link the database resource to the web site at this point.
Update config
The only config setting to update is the database connection string. You'll be able to find the connection string from the database section within Windows Azure. Connecting to a SQL Azure database is pretty much the same as any other database or database server.
Deploy site files
You can either copy all your files to the site via FTP or use Windows Azure's automated code deployments. We prefer the latter as Azure will build the application before deploying. We use Bitbucket to host our repositories. Bitbucket has been integrated into Azure's deployment section within Azure Websites. This makes it easier to deploy straight from source when pushing to specific branches.
That's pretty much it. The only caveat is handling media files can be a little tricky. As long as you don't have any in source control or at least, a reference to the media folder within your solution, Azure's deployment will not overwrite your existing media items. Using Azure Storage would be a better solution but we've found it be a little tricky when scaling Azure Websites to multiple instances.