How to Migrate a Website to a New Host With Zero Downtime

August 29th, 2011

You are about to gain a new customer. The customer is currently with some other host and wants to migrate to your service. However, he is worried about down time. When he migrated before, his website was down for almost a week. What to do?

Tell him you can migrate him with zero down time.

Here is why there is an asterisk on that statement: SSL services. SSL unfortunately require 3rd-party registrations and static IPs. You simply cannot migrate those seamlessly. However, anything shooting out of http port 80 (or mail ports 25 or 110 – described later) is fair game to the zero down time trick. Here is an overview of what you need to do:

Before you change the DNS to point to your new server, you need to set up the new server to behave identically to the old one. That way, as the DNS is fluctuating between old and new, no matter where the user is taken, he will receive the same page. This is how zero downtime is achieved!

Here is the diagram after DNS has resolved:

Here are the steps to do this:

Log in to the customer’s cPanel (or Plesk, or SSH) of the old server and take a look around. Download all the files and upload them to the same location in the new server. Do the same with the database too. You can do this with phpMyAdmin using the export/import utility. If you have the ability, you will need to give the new database the same username and password. If you don’t have that level of access (which is most people, including cPanel resellers), there is a workaround. It requires knowing PHP code (or whatever code is used in the customer’s CMS, which is most likely PHP). It is not too difficult. Here is how:

Find the area in the user’s CMS where the database connection is being made. Add this and tailor it to your needs:

<?php

if(stristr($_SERVER['SERVER_NAME'],"192.168.1.126")!=false) //The OLD IP!

$oldDB=true;//still at old host!

else

$oldDB=false;//We have migrated!

}if($oldDB)

$dbname='oldDBname';

$dbuser='oldDBuser';

$dbpass='oldDBpass';

else

$dbname='newDBname';

$dbuser='newDBuser';

$dbpass='newDBpass';

}/* Their database connection method may be different */

try

$dbhandle=new PDO("mysql:host=$dbhost;dbname=$dbname",$dbuser,$dbpass);

catch(PDOException $e)

echo "Error!: " . $e->getMessage() . "<br/>";

die();

?>

This bit of PHP code will detect if the DNS resolved to the old server or the new server. Depending on the case, it will set up the database to act accordingly.

Bonus points: Make the site read-only if it is resolving to the old web host. Any changes made to the old web host will not be carried over to the new! The good news is that DNS should not be fluctuating for more than a day (often resolved within 4 hours), so updates can continue again.

To do this, you could remove write permissions of the database user in cPanel. Depending on the CMS, this could simply cause the site to break and cause all sorts of problems. CMSs expect to be able to write to their database. An easier solution would be to throw up a banner saying the site is read only and leave it be. Here is an example banner:

<html>

<head>

<title>My website</title>

<style type="text/css">

#readonlybanner {

margin:0 0 0 0;

border-width:1px;

border-style:solid;

padding:12px;

color:#CC0000;

background-color:#FFEBE8;

border-color:#CC0000;

text-align:center;

</style>

</head>

<body>

<div id="readonlybanner">

<p><strong>Any new post may be lost as we update our system.</strong></p>

</div>

</body>

</html>

Now, users are warned to not bother posting.

Here is what they will see:

If you don’t want to bother with CSS and HTML, feel free to just save a copy of that image.

Another bonus point: Set up the mailboxes with the same usernames and passwords so email keeps working! (The ports 25 and 110 referenced above are the default mail ports.) Note: You cannot do this if they are using SSL to fetch their mail (and using SSL is always the recommendation). You don’t have to worry about this if they are using a different email provider than their web host (such as Gmail).

If the email cannot be set up to work the same as before, here is a workaround: Set up a 2nd account on their outlook that fetches from the new address. So when old server dies, the new server takes over.

Here is a way you may do this:

outlook account settings

There are 2 accounts. One with the old, and one with the new. When the old server quits working, the new server will seamlessly kick in. That way there is zero email down time. After the transition, the users may delete their old accounts.

Potential down time is one of the biggest reasons a customer may stay with their old host. Your customers will be very appreciative of you going the extra mile to reduce it.