Faking a very fast DNS change and propagation

So you need to transfer high traffic, dynamic site with the minimum possible amount of down time.

Just reducing the DNS TTL's won't always work as expected, as many providers have been reported to ignore the TTL values.

So, instead of just changing the TTL to a small value and pray, there is a small hack you can apply to this particular situation.

Disclaimers:

• This solution only applies to web traffic. For other types of data (such as email) it offers nothing.
• This assumes that you are using Apache as your webserver, although the same principle should apply to other webservers as well.
• I assume you know the basics of a domain transfer. This guide does not go into much detail about managing DNS records.

Phase one (a couple of days before the move)

Change your DNS TTL values to a smaller value. Typically this would be set to 86400 seconds (24 hours) or maybe 14400 (4 hours).

Specifying a minimum TTL depends on your server's traffic. Set it too low and you'll get flooded with DNS queries. Set it to high and you'll need to wait longer for the DNS change to happen (this will not be much of a problem with the method proposed here, it will just be... longer :)) Let's say you set it to 1800 seconds (30 minutes). This will take 36 to 72 hours to propagate across the internet, though as previously mentioned, some clients may choose to ignore this, therefore you can't count on that. Create the vhost for the domain that should be moved on the target server. Make sure mod_rewrite is enabled on the old server (you are going to need this later).

Phase two (t minus some hours)

Make sure your code is in place and running on the target server (do a test migration of the database and content). Create a new subdomain (vhost) on the target server called something likemigration_temp.<your-domain-name.com> (don't worry, this wont be visible to your visitors - you can name it whatever you want). This subdomain should be serving the same content as the domain you are moving, so make sure it points at the same path as your domain. Careful: use a non-existant subdomain, so that you wont have to worry about it's DNS propagation. Add a new A record for this subdomain to your DNS server with the IP of the target server.

Phase three (changing the servers)

Crack your knuckles for this one. The actual down time depends on how quickly you can move your database and content files from one server to the other. When ready to move, make sure that no further changes can be made to the old server (through a maintenance page or something like that). Then move the databases and content files to the new server. Here come's the clever part. On the old server, add an .htaccess file on your site's base directory with the following lines:

<code>

Options +FollowSymlinks RewriteEngine on RewriteRule

https://migration_temp.your-domain-name.com/$1

</code>

 What this does is act as a proxy, redirecting all requests to the new domain. This is transparent to your visitors - they still see the standard domain in the URL. Hard part is over. Re-enable your site and all requests should now be served by the new server. We still need the old server to temporarily proxy the requests to the new one. Sit back and relax a bit as the load lingers on the old server, while starting to thrive on the new one. Then, go ahead and change the DNS records to direct to the new server. (Don't forget to restore the TTL to something more practical). After a few days, you can confidently disable the old server.