Dennis Burton's Develop Using .NET

Change is optional. Survival is not required.
Tags: Azure

There is no shortage of great material out there to help you build your next application on the Windows Azure platform. What I will do in this series is show the process of migrating an on-premises web application to Windows Azure. What you will see over the next few posts is an application that I built for to help prioritize questions during the Azure Boot Camp events. The application is built using the tools and patterns that I use today to build web applications. You will see appearances from MVC2, Fluent NHibernate, MVCContrib, and the Windsor Container.

Many of these tools were added to the project with minimal effort using NuGet. One of the features that saved time on this project was the ability of NuGet to add assembly binding redirects for projects that have dependencies on multiple versions of a library. The Add-BindingRedirects call from the Package Manager Console took care of this problem for the Castle.Core assembly which had bindings to 1.x and 2.x versions of this assembly.


I leveraged the repository pattern whose only public methods were calls for data operations that were required to build the application. Additional code was not added to support CRUD operations on every single element of the model, when there was no requirement for this functionality. As the migration progresses and the data access code is replaced, this repository tells us exactly which operations need to be supported.

You will also see the use of the view model concept. The controller will fetch the required model data and perform the aggregation necessary to present exactly the information that is needed by the view. This approach allows for much thinner view code allowing the HTML of the page a higher percentage of the code.  Check out the spark view engine or the upcoming Razor View engine in MVC3 for even cleaner views.

Planning the Migration

Just as with any application, the migration will not take place in one step. When performing a migration from on-premises to the cloud, it is even more important to consider where you will get value in migrating first as well as reducing the cost of the intermediate steps intended only to assist in the process of migration. This is the order that I chose to do the migration and my justification for that order.

Step 1: Migration to SQL Azure

Infrastructure - It is easier to point your on-premises app to the SQL Azure instance by changing configuration settings than it is to open up your database server that is likely sitting behind a firewall(s) not visible to the outside world. There is a non-trivial amount of infrastructure work necessary to make that happen. Since we know that our next step will be the migration of the web hosting to Windows Azure, I would choose not to take on that work that would be thrown away once the web instances are relocated.

Cost – Cloud pricing is a very dynamic point and one that changes for each scenario. I can only speak to the scenarios I have worked with in the past. Your scenario may be different, do your own math. In the larger web applications I have worked on, the database hardware was the most expensive hardware purchased and the licensing cost for SQL Server in an Active/Passive configuration is non-trivial. When moving to SQL Azure, the licensing and the failover support are built into the cost. If you are looking at version upgrades in the near future, this kind of migration might just be a good deal for you.

Step 2: Migration of the Web Servers

Missing Pieces – This application does not have an app server doing a lot of data processing. If it did, I would choose to migrate those processes first. The processes that are doing the heavy lifting with data need to sit as physically close to the data as possible in order to have reasonable performance. Another important consideration is that this type of code usually has the fewest dependencies. That reduces the work load of verification once migration of this step has completed.

Infrastructure – Once this step is completed, the application will run entirely on Windows Azure allowing us to decommission or repurpose the on-premises hardware. If you are already building applications to scale well with your own hardware, it is likely that there will be few things to be modified to run in a web role.

Step 3: Migration to Cheaper Storage

Where it makes sense, we are going to look at migrating data to Table Storage where the charges are (as of this writing) $0.15 per GB/month vs. $9.99 per GB/month on SQL Azure. The planning for this stage will require us to look at our data consumption patterns. While SQL Azure is quite a bit more expensive for storing our bits, there are no charges for transactions. With Table Storage there is a charge for each request that leaves the data center. Since we have already migrated the web site in the previous step, we will make sure that our data stays inside the data center to avoid these charges. Be aware, changing the storage mechanism is a non-trivial change that includes restructuring our data as well as modifying our repository layer to talk to a different style of data storage. There is a different mindset around designing for Table Storage instead of a relational database.

What is your migration story?

Have you done a similar migration to the Windows Azure platform? I would love to hear what the decision points were for your migration as well as your lessons learned. Feel free to comment on these posts or contact me directly with your feedback.

Please login with either your OpenID above, or your details below.
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, strike) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview

Dennis Burton

View Dennis Burton's profile on LinkedIn
Follow me on twitter
Rate my presentations
Google Code repository

Community Events

Windows Azure Boot Camp Lansing GiveCamp