Azure Migration Workshop

One of the engineers on my team and I recently participated in 2-day Azure (Microsoft’s cloud) Migration workshop. We successfully deployed 2 organizational applications and a SQL database and learned a lot from the exercise. While we were there I jotted down some of the lessons learned and thought that others might find them interesting...


SQL Azure Migration
• 50GB database size limit (in relational DB format)
• Oracle databases will need to be connected to on-premise
• Need to use SQL Server authentication model
• SQL queries used by SQL Azure are slightly different from the original script...code migration wizard alters them, but the tool is still not very mature
• Cross-DB dependencies and communication is not supported...neither is distributed transactions
• SQL Server migration wizard (from Codeplex) can be used to analyze and point out DB incompatibilities before conversion to SQL Azure
• Every SQL Azure DB table must have a clustered primary key

Windows Azure Migration
• Applications need to be in .Net web application (not web site) format
• Must include Cloud project within .Net solution
• Cannot use Windows authentication model without using an AD federation-like model
• AnonymousAuthentication web.config setting is not recognized
• The WSDL of web service sites gets the port 20000 injected at the point of deployment
• Observation: deployments take a LONG time (plan on going to lunch)
• SMTP capabilities are not yet available in the Azure cloud (would have to use an on-premise solution)
• Cannot use regular file-system reading/writing
• Need of URL Mapper for Staging environment...a unique URL (GUID) is generated with each deployment
• Each web.config change, no matter how small, requires a full package redeployment
• David Pallmann's Technology Blog is a good Azure resource
• The number of "instances" in the Cloud Project configuration file reference how many VM instances are to be built
• The csfg (Cloud Service configuration file) file is the singular file (custom zipped) that gets deployed
• The word "global" cannot be used within an Azure cloud URL and Service Names/Labels are unique across the entirely cloud.
• Cannot reference anything within the machine.config file...must be moved to web.config
• At this time only 3rd-party vendors are coming to the table with VM usage monitoring tools -- this space is still very immature.

Dev Fabric
• Enables developers to build, debug, test code locally as a Cloud project before deploying to the Cloud.
• Just because .NET code runs locally using the DevFabric with a Cloud project included in the solution doesn't mean that it'll run in the cloud. Code has to be tested in both environments.
• Runs on the same OS as the local test machine. Beware: Cloud VM's are x64 slightly-tweaked W2K8 server.
• Is not a good indicator of performance…very much based on local hardware specs.

Billing & Portal
• The Azure portal makes it very unclear and difficult to determine your usage statistics for the billing month.
• BEWARE: each MSDN account holder receives 750 free hours of Azure platform which goes quickly even with only a couple of small applications and a DB deployed.
• Hours billed are for platform usage, not application usage.

Other Things to Note
• To use your own domain it is necessary to setup a DNS Cname that redirects the company URL to the Cloud URL.
• The Package configuration file (cscfg) can be changed and uploaded on the fly (# of VM instances specified in this file). Changes to the Service Definition file (csdef) however require a redeployment.
• Think of Windows Azure roles as type of VM's you'd build internally (i.e. Web Server --> Web Role, Application Server --> Worker Role, etc.).