5 steps to a painless Cloud migration

A common concern that many of our clients have brought to us is a hesitance to migrate existing applications into the Cloud. They see the promise of the Cloud -- lower cost, infinite scalability, and high availability, but they believe that migrating their legacy apps into the Cloud will be expensive, time consuming and distracting. In short, they view a migration as a big risk, even if there is a big reward. We understand those concerns, but our experience has been that a migration to the Cloud can be quick and pain free. As with any large project, the key to relieving the concerns is proper planning and a good roadmap to get from here to there. In this post, we'd like to share what we at quicloud do when bringing a client into the cloud.

1) Educate yourself about the Cloud, as well as your current infrastructure

  1. Calculate potential savings. Get a rough picture of your current infrastructure, and calculate equivalent cost in the cloud. You can get a very good "back of the napkin" estimate of your cost savings by simply getting the CPU and Memory footprint of your current machines, as well as your current bandwidth usage, and then look up prices at Rackspace Cloud and Amazon EC2. Once you've verified the savings (50-70% less than what you're paying for hosting now, by our experience), it could provide you with the ammo you need to sell the effort to your management.
  2. Assess Security. Assess which parts of your application (typically Database) must either reside in-house or at a a Managed Host. If your apps have any HIPAA or PCI requirements, learn the impacts of moving them to the cloud as well.
  3. Hire Pros. Bring in professionals and leverage all their successes (and failures). Lots of other folks have made the discoveries and encountered the pitfalls -- seek out these experts and use their experience to catapult your project ahead. Depending on the project, Education can be as quick as a 30 minute consultation (for a simple CMS migration like Wordpress, Drupal) and as involved as a 2 week "deep dive" into advanced topics like Hybrid Environments, Private Clouds, and Heterogeneous deployments (like leveraging multiple cloud providers such as Rackspace Cloud and Amazon EC2). Especially at these initial stages, a cloud expert can provide invaluable insight and get you and your team up to speed quicker than they could on their own.
  4. Resources. Starting from most basic to most in-depth, here's a few resources to get you started.

    Cloud Computing Explained (short video covering basic Cloud Concepts)

    Blogs:
    Thinking Out Cloud by Geva Perry
    GigaOm (do a search for "cloud")
    Elastic Server Blog

    List of Cloud Platforms, Providers, and Enablers
    http://groups.google.ca/group/cloud-computing/web/list-of-cloud-platforms-providers-and-enablers

    Rackspace Cloud Servers Wiki (small but growing):
    http://cloudservers.rackspacecloud.com/index.php/Main_Page

    Amazon EC2 Documentation (often contradictory & sometimes out-of-date, but extremely comprehensive):
    http://aws.amazon.com/ec2/faqs/

2) Define the desired outcomes

After you understand what the Cloud is, and how it can change what you do, ask yourself what you want to accomplish from a migration. Brainstorm a list of everything you could accomplish, and then one by one add them to the priority list by asking the question "If we could only do one of these, which would it be?". After doing this exercise with your team, you should emerge with a prioritized list of what you need done. Some questions you should be asking are:

  1. Shore Up or Leapfrog? Are you looking to just enhance your current systems (such as utilizing a physically distributed CDN), or are you looking to jump ahead in the cloud, possibly re-architecting your apps & infrastructure to do things (like autoscaling) that were not possible in your old infrastructure?
  2. Compliance + legality issues. Not an issue for most small companies, but if your organization requires any HIPAA, PCI, or SAS compliance or audits, make sure your legal & compliance teams are aware of (and bless) your steps into the cloud.
  3. Failover, High Availability, Dealing with manic load. Individual data centers go down, even in the cloud. Are you architecting your systems to not rely on any individual data center's availability? Do email blasts or periodic events require your servers deal with extremely low load one day and then extremely high the next?
  4. Plan for multi-server "SESSION" handling in your application. In a multi-sever environment, you need a reliable way to handle sessions across the servers. The two best methods we can recommend are: 1) Utilizing a load balancer to "stick" a single user to a single server; 2) Utilizing a "common" session mechanism, with memecached or another cache system centralizing sessions & sharing them among your servers -- this is generally a slower and more fragile approach than #1, but there are places it makes sense.
  5. Take baby steps An expert we recently saw speak said it best -- "we all take baby steps, I've just taken more than you". Start small and make the small mistakes before trying to tackle big problems. Only attempt to define a long-term Cloud Roadmap after you've got several successes under your belt.

3) Set up QA and monitoring scripts

You'll need to baseline the behavior of your existing site so you can verify it's proper operation after you've migrated.

  1. This can be as quick and low cost as 3 hrs / $150 to build an extensive test of a simple Real Estate agent's Wordpress site, and it's generally not more expensive than $1500 to build an extensive suite for a medium-sized dynamic app.
  2. A nice side-effect is that the scripts you build can become part of a Continuous Improvement and QA Deploy process (something you should have already).

4) Do a series of Test Migrations to find + work out the kinks

Migrate the site to a "test" cloud, and do exentsive internal testing against all of your concerns, use a tool like Jmeter to verify how much load your new site can take, and investigate what is off if it doesn't meet your expectations.

  1. Run a load test on your migrated infrastructure & see if it's performing as expected.
  2. Take your time & try to break things -- you won't get such a chance when you try to cut over live.

5) Prepare for live cutover to migrated site

  1. Write a granular step-by-step script/checklist of what you need to do to for the cutover to live. An ex-marine friend constantly reminds me of the USMC's "5P" stance regarding something like this -- "Prior Planning Prevents Potential Pitfalls". Checklists, checklists, checklists...
  2. Plan for database dumps & outages. You'll need a snapshot of your user data at the very last second before you bring your site down to dump the database. Plan for disruption (schedules, product availability) around the days/hours that your migration will take place, and plan to have your team working in the middle of the night when load is generally it's lowest.
  3. At a week in advance, set DNS TTLs down to 300 seconds at most (and 30 seconds, if possible). This gives you the chance to quickly roll forward (and back if anything breaks).
  4. Put your top pessimist in charge of building a rollback strategy. Don't assume that any part of the migration will go smoothly… instead, ask and answer the the questions of what would happen if everything went wrong. It's almost a given that some part of your cutover will not go as planned.
  5. Perform a "test" run if time/budgets allow. It's easy to spin up a bare metal Cloud Server & run through your migration script with it, and it could highlight issues that you'd have when you do the real thing.

We hope the tips above help you with your migration, and we'd love to keep improving on this list in order to help others.

We'd love to hear your feedback -- things you've found useful, troubles you've had.

Is there anything you think we missed in our list? What lessons have you learned from your migration to the Cloud? Please post your comments below.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

PCI Question

We're planning a migration from a local hosting company to AWS and your tips have been very useful. Some of our platform needs to be PCI compliant and would like to know your recommendations on how to get certified.

Which level of PCI?

Hi Jake,

Thanks for the comments. There are 4 different levels of PCI, and which you fall into is determined by the annual transaction volume that you service -- check http://www.elementps.com/merchants/pci-dss/compliance-level/.

At the very least, you'll need some PCI-compliant security scanning done on your machine(s) to identify gaps and provide us with a remediation plan. quicloud offers both scanning and remediation services, and we can help with all aspects of your PCI certification. Please either shoot us an email to "sales at quicloud dot com" or give us a call at 303 325 5820.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options