How to migrate legacy apps to Windows Azure

I see a lot of interest by startups to start using Windows Azure to power their products. It's the perfect platform to start small and have room to scale quickly and easily. But the most important advantage that startups have, is not having to worry about legacy issues. 

A lot of companies would like to start using the cloud. By now, we know what the advantages are: scalability, resiliency, low management overhead, low service costs, etc. However, most companies out there are not lucky enough to have new products to launch regularly. Most companies already have a platform that they've invested years of development and tons of money (possibly literally!) in, and it's crazy to think that they need to start from scratch just to take the trip to the cloud. If you've got a brand new product to work on, great! Start thinking about the cloud from day 1! For the rest of you, I say you don't need a rewrite. 

I know most developers think rewriting is always great, but there are pitfalls. You will be replacing code that's been tweaked year after year and been working error free with brand new (possibly) bug-laden code. You can test all you want, but the reality is that you can never compare your efforts with a 5-year period in the production environment. System rewrites are usually followed by a big bang launch, with the next few weeks (months?) serving only to fix, tweak and educate your clients. Unlike developers, users generally don't like to be surprised. They'd like you to ease changes bit by bit, and a rewrite would definitely be a shock. 

Instead, you need to focus to refactor code incrementally. Make a plan and be specific. Think about which areas you'd like to target before others, and give priorities accordingly. Target areas individually and avoid starting from scratch when possible. If you use SCRUM, start introducing refactoring stories into the product backlog and get your product owner onboard. Reuse code that works and improve code that doesn't. Investigate and understand which areas are not tailored for the cloud and consider using short to medium term solutions as well. Even if you do not move to a fully automated Platform-as-a-service model, moving your service to a basic virtual machine can give significant advantages too!

Before you begin

Some apps are more 'legacy' than others, but the main problems remain the same. Here are some guidelines to consider before moving your legacy app to the Windows Azure.

1. Know your application well

You will not have a successful migration if you do not know the system well. Period. Explore how it works. Have a clear idea of the present architecture. Do not limit yourself to the running code but include the system as a whole, including backup processes, software versions and dependencies.

2. Know your licensing

Well, people need to eat. Chances are, you respect that so whenever you need a piece of software, you will pay for a license. Check if the licenses are transferrable to a cloud environment. Be wary of licenses that are server specific in some way. Some licenses might be IP bound, or hardware bound (MAC address?), which sucks. Remember that you cannot transfer your current IP address to Windows Azure so you will have to use one of Microsoft's IPs. 

3. Know your uptime requirements

Do you need to have a disaster recovery site? Do you need high availability? If so, you need to realise that these cost money. You may need different editions of software (which SQL Server edition should you choose?) or will have a different topology. Remember that Windows Azure does not give an SLA with a single VM for both Infrastructure-as-a-service and Platform-as-a-service offerings. Do you need to move your application to a multi-instance environment? Make sure you incorporate these requirements into your plan.

4. Know your current costs

If you plan to move to Windows Azure, or any cloud for that matter, you need to know why you'd like to do it. If the move is related to cost, make sure you compare like-with-like. Remember that the cost of a single virtual machine in Windows Azure includes invisible costs such as electricity supply, cooling, standby engineers, automatic healing etc. Most on-premises environments will have a different cost distribution so be aware of the real cost. Even if the reason you are migrating to Windows Azure is another, knowing your costs well lets you plan better for the future.

5. Know your restrictions

Some projects are restricted artificially in some way. You might have clauses in your client's contract which limit services or data going outside of a specific region (Europe?) or country. Although Windows Azure has a range of datacenters around the world, there isn't one in every country. Some projects require certain infrastructure standards to be adhered to. Refer to the Windows Azure trust center http://www.windowsazure.com/en-us/support/trust-center/ for a list of certifications and standards that Windows Azure complies to (they recently added PCI DSS level 1, amongst others).

In my next post, I will list some common issues that a lot of people starting up in Windows Azure encounter, and how to best solve them.