These are not meant to be comprehensive step-by-step, ordered project plans with task dependencies. These are checklists in the style of those used in other industries like Aviation and Surgery where complex projects need to be performed. Their goal is get the known tasks covered so that you can spend your energies on any unexpected ones. To learn more about the practice of using checklists in complex projects, we recommend the book Checklist Manifesto by Atul Gawande.

Your project manager should adapt them for your project. If you are not familiar with some of the technical terms below, don’t worry: Your engineers will understand them.

Pre-Cutover Migration Checklist

The pre-cutover checklist should not contain any tasks that “set the ship on sail”, i.e. you should be able to complete the pre-cutover tasks, pausing and adjusting where needed without worry that there is no turning back.

• Set up communications and collaboration
  • Introduce migration team members to each other by name and role
  • Set up email lists and/or blog for communications
  • Ensure that appropriate business stakeholders, customers and technical partners and vendors are in the communications. (E.g. CDN, third-party ASP)
• Communicate via email and/or blog
  • Migration plan and schedule
  • Any special instructions, FYI, especially any disruptions like publishing freezes
  • Who to contact if they find issues
  • Why this migration is being done
• Design maintenance message pages, if required
• Setup transition DNS entries
• Set up any redirects, if needed
• Make CDN configuration changes, if needed
• Check that monitoring is in place and update if needed
  • Internal systems monitoring
  • External (e.g. Keynote, Gomez)
• Create data/content migration plan/checklist
  • Databases
  • Content in file systems
  • Multimedia (photos, videos)
  • Data that may not transfer over and needs to be rebuilt at new environment (e.g. Search-engine indexes, database indexes, database statistics)
• Export and import initial content into new environment
• Install base software and platforms at new environment
• Install your Web applications at new environment
• Compare configurations at old environments with configurations at new environments
• Do QA testing of Web applications at new environment using transition DNS names
• Review rollback plan to check that it will actually work if needed.
  • Test parts of it, where practical
• Lower production DNS TTL for switchover

During-Cutover Migration Checklist

• Communicate that migration cutover is starting
• Data/content migration
  • Import/refresh delta content
  • Rebuild any data required at new environment (e.g. Search-engine indexes, database indexes, database statistics)
• Activate Web applications at new environment
• Do QA testing of Web applications at new environment
• Communicate
  • Communicate any publishing freezes and other disruptions
  • Activate maintenance message pages if applicable
• Switch DNS to point Web application to new hosting environment
• Communicate
  • Disable maintenance message pages if applicable
  • When publishing freezes and any disruptions are over
  • Communicate that the Web application is ready for QA testing in production.
• Flush CDN content cache, if needed
• Do QA testing of the Web application in production
  • From the private network
  • From the public Internet
• Communicate
  • The QA testing at the new hosting location’s production environment has passed
  • Any changes for accessing tools at the new hosting location
• Confirm that DNS changes have propagated to the Internet

Post-Cutover Migration Checklist

• Cleanup
  • Remove any temporary redirects that are no longer needed
  • Remove temporary DNS entries that are no longer needed
  • Revert any CDN configuration changes that are no longer needed
  • Flush CDN content cache, if needed
• Check that incoming traffic to old hosting environment has faded away down to zero
• Check that traffic numbers at new hosting location don’t show any significant change from old hosting location
  • Soon after launch
  • A few days after launch
• Check monitoring
  • Internal systems monitoring
  • External (e.g. Keynote, Gomez)
• Increase DNS TTL settings back to normal
• Archive all required data from old environment into economical long-term storage (e.g. tape)
• Decommission old hosting environment
• Communicate
  • Project completion status
  • Any remaining items and next steps
  • Any changes to support at new hosting environment

Briefly, I covered details of our move and some best practices that we currently follow and plan to follow in the future.  I also gave some statistics and hard numbers to help people make their own decisions about moving to the cloud.

You can see the entire presentation or watch below.

One of the debunked myths we heard mentioned at the conference referred to the nature of the average company using AWS. Many assume that it is primarily small start-ups, with simpler infrastructures, that are most likely to leverage technology. Although newer companies are more likely to begin building an IT infrastructure in the cloud (compared with those who have already invested in a legacy infrastructure), there are in fact a significant number of larger enterprises that have migrated (or in the process of migrating) to a Cloud model.

Our presentation covered some of the pain-points in migrating a multi-layered architecture into EC2. One of the bigger take-away messages is that it is often a best practice to migrate in phases. This process is often made possible through the use of VPN, in order to merge a legacy IT infrastructure (and network) with the virtual instances in EC2. Amazon offers a service called VPC (Virtual Private Cloud) which simplifies a means for securely merging an internal and cloud-based network. In our presentation, we discussed how Reddit accomplished a similar goal through the use of OpenVPN (only because VPC was not yet available from Amazon).

Please feel free to view a slideshow of our presentation here.

Our presentation (as well as Jeremy’s presentation from last week) will hopefully begin to erode the mindset that the Cloud is ideal for smaller and simpler applications. We are only beginning to leverage cloud platforms on the projects we will be discussing on Monday, but the potential and current results have been significant. Wired.com and reddit.com both represent high-traffic websites with architectures that are comprised of multiple layers — designs that are not typical of what is currently considered the norm for applications running on EC2 or Google AppEngine. We are hoping that our presentations will bring more awareness and legitimacy for using Cloud Platforms within larger enterprises — either as the entire infrastructure, or for augmenting a legacy or dedicated hosting model. We will also discuss the benefit of using cloud platforms for testing and staging endeavors.

We will be sure to post the final presentations on the website as soon as they are available. However, if you are in the New York area, we recommend stopping by if you have signed up for the event. You can find more information about Amazon’s Cloud for the Enterprise event on their website.

Werner Vogels, CTO of Amazon.com will be the headline speaker for this event, so stay tuned for updates on Werner’s talk and further details on the event.

This site was founded by Paul Tepper Fisher, Rajiv Pant and Jeremy Edberg, authors of the upcoming book Revolution:Cloud — The Guide to Cloud Computing for Business and Technology Leaders, published by Apress.