The challenge of migrating any application is, more often than not, a worthy architectural and business exercise. Its worth is in lock step with the value of the application – its usage and importance. It can result in benefits for the users (e.g. access and performance) and the business (e.g. agility and cost).

When considering migrating your applications to the “cloud”, there are several considerations that I believe are universal. For Windows Azure the migration effort could be as little as a packaging (zip-ping) exercise, since you don’t have to change your application to match the platform. Your application will work out of the box, but it may have unexpected side effects.  It could be already architected and designed to work well as a Azure application, though the older your application the less likely this is to be the case. In essence your application should deal with two things: traffic being load balancing and data persistence.

Its more likely, that as an application is migrated, that its on premise roots are exposed. So, rather than uproot the application, it is important to consider application migration as part of a process.  For example:

image

When determining migration complexity there are tools to help such as the Migration Assessment Planning Tool. However I propose there is an easier practice for performing a quick check on your application. I use these basic categories:

Consideration Action Description
Packaging Mandatory

Application parts that are required to be unpacked by Azure for setup

Persistence

On review

All data stored should be accessed in a cloud friendly way

Stateless By design

The execution is consistent regardless of which compute instance is runs on

Configuration On Review

Parameters the application leverages that can change periodically

Resilience

By design

The application tolerance to manage failures (e.g. retries)

Legacy

On review

The degree to which the application relies on traditional or unsupported frameworks

To put this into context, and the topic for my next blog post I’d like to  illustrate this in light of my experiences of migrating the .net Pet Shop 4.0 to Windows Azure.

 

Consideration Findings

 

Packaging

Most of the effort was in converting web site to a web application

Specifically

  • Profiles
  • Add Cloud Project/ Configure

Persistence

Since there were multiple SQL databases, some  effort was required to:

  • Consolidation of databases
  • Use of a single database (rather than DTC)

TODO:

  • CDN

Stateless

For the application to manage state, there were some changes to its use of:

  • Cache Dependency
  • Configuration

TODO:

  • ASP Membership

Diagnostics

There was very little diagnostics so added logging and performance counters for roles to make user of the Windows Azure diagnostics

Resilience

None – TODO!

Legacy

There were a few considerations of older frameworks and practices including:

  • MSMQ
  • Encrypted connection strings

In addition there are some migratory considerations in terms of security.For the .Net pet shop this was simply the firewall rules for SQL Azure but it could have included HTTPS portions of the site, and therefore certificates, or indeed payment gateways etc.

All in all the effort in migrating this application was around 1-2 hours but repeatable in roughly 15 minutes. The wider ramifications of management, and proper feature inclusion (such as the CDN) would require some thought and extra time, but I expect it would be nothing too significant.

What I learned from this exercise, was that migration is not trivial, but its also often a mental rather than a heavy lifting exercise. Its also an exercise where you can quickly determine the suitability of migration. Almost all applications could be migrated but some perhaps shouldn't – which us back full circle to the business benefit of migration. If migration to the cloud is too difficult then its probably worth considering how you use Windows Azure rather than how you move to Windows Azure.

For more information on migration the MSDN Azure portal offers quite a bit of advice in addition to the following I read: