There comes a time in every website's life when it must grow up and leave behind the infrastructure that got it to where it is. As traffic scales up, site uptime and speed become paramount; Web hosting companies are compared, and finally it is time to move house, i.e. to switch Web hosting companies. Moving sites without a glitch is important, even critical, and with some experimentation, I hit upon a checklist that should help anyone plotting a move. Follow these steps and your site will remain up throughout the move and your site visitors and online business teams will thank the IT department for its forethought.
1. Move When the Traffic is Low. Just like the maintenance crews working on our freeways between 2-5 am, find a 8-12 hour window where it matters less if someone can't get to your site, or if you can't get to your email. I started Friday evening, with a glass of wine in hand, but decided to only start the DNS name server move on Saturday morning, when I would be wide awake and the developers available to fix problems.
2. Switch Your Email Profile at Both Web Hosting Companies. Let's say your domain is mysite.com, and your email address registered at the Web hosting accounts is email@example.com. Change that to a Gmail address, because if, during the name server move, if your domain's email goes down, you will at least be able to create support tickets and respond to them using your Gmail address.
3. Create a Mirror Site and Monitor It. First, completely replicate your site from Web hosting company A to B, and setup site performance monitoring on both sites. Run it for a few days to ensure that there are no content, database, or networking problems.
4. Copy and Import Your Zone File. Your DNS entries are stored in a file called a Zone file. Find out if your current Web host gives you the ability to export that Zone file, and if so, import that Zone file as is at your new host. Sometimes, you can't do this, in which case you will need to manually recreate the DNS settings on the destination Web host. Remember to print out your DNS records so that you know exactly which A, CNAME and other entries you need to make.
5. Setup a Virtual Host at the Destination Server. Since you already setup your mirror site at the destination host, all you need to do is create a "symbolic link" to your domain. As an example, if your original site is mysite.com, and you setup a mirror site mysite-copy.com, what you need to do is to setup your destination servers to accept visits to mysite.com, once the DNS move begins. I was using Linode, and while they didn't specifically give me the recipe to do this, I configured a virtual host to point to the servers that I had already setup at the destination Web host. Linode in particular has great documentation, so it's easy to figure it out.
6. Start Your DNS Move. Once you're ready, go to your source Web host, and change your DNS servers for your domain - this begins the move! Pour yourself another glass of wine, and keep the bottle handy for refills. My poison of choice was a Chianti Ruffino.
7. Monitor the Move Using Website Performance Monitors. If you have setup 24x7 performance monitors that robotically visit your site from locations around the world, expand the geographies from which you're monitoring your site. You want to know if there's a problem in a particular city. I used Keynote and, for extra measure, Pingdom, to keep an eye on both performance and availability of the sites. Something I was able to do with Keynote, but not Pingdom, was to alert me if content was missing on the site after the move.
8. Setup Availability Alerts to Fire If Content is Missing. Site availability alerts usually fire off in Keynote or Pingdom if your site is completely down, or (in the case of Keynote) if page performance falls below a threshold you previously set. I configured Keynote alerts so that if a page was missing content, that should be considered as if the site were not available. Initially, Keynote alerts were firing off like crazy, as the picture below shows - all the yellow data points show individual tests Keynote made, and where the base page returned successfully, but was missing content.
9. Conduct a Traceroute Test from All Over the World. I remembered that Keynote allows you to run network diagnostic tests, such as ping, traceroutes, and TCP traceroutes, from any of their thousands of agents located in cities all over the world. You can only do a test from 16 locations at a time, but that was enough to show me that DNS remapping had not completed, and therefore, the site was not resolving to the servers at the destination host in all locations. In the tests below, you can see some of the windows where the traceroute resolved to my old Web host, and so I knew that those locations were not seeing content from the new Web host.
10. Tweet and Enlist Your Customers. Finally, as the DNS change was propagating around the world, I also asked the site developers to throw out a tweet to thousands of their followers, and enlist the help of the crowd to check site uptime from places all over the world. Keynote actually has a crowd-testing tool to allow you to do this, called WebEffective, but I took the free route. Within minutes we got email reports from followers, telling them that the site was up or not, and we were able to isolate problems to a handful of ISPs, where, apparently, the DNS propagation had not reached, 24 hours after the move.
And that's all folks! These 10 steps ensure that your website remains up and running during any change to its infrastructure. Follow them, and mimize or eliminate all downtime. And, in tribute to the Italian wine that keeps you company during the website move, Cin Cin!