How to change web host for my small site with minimal downtime

Company S is a small mom and pop host that can't keep our site running for more than a couple weeks at a time. They have suggested we find a better home. So we are moving our site to CrystalTech for hosting in their shared plans. I have moved the site over and it is working fine on the IP address, but now I need to move the name servers, and how do I minimize downtime

Here is my plan, please point out any errors:

  • On Monday, ask Company S to reduce the TTL on our name to something very small, perhaps 1200
  • On Friday ask Company S to change their DNS to point our domain to the IP address at CrystalTech. Just the web and not the email.
  • At the same time change the ns records with network solutions to CrystalTech's nameservers
  • At the same time disable the database on Company S and change the template to read "sorry, site moved blah blah blah"

I hope those four steps make the transition basically buttery smooth for everybody at once and nobody sees the "sorry site moved" for more than a 20 minute window

Will this make the transition as smooth as possible? We don't have anything super time sensitive like a shopping cart, but users do log into the site and update forms dynamicslly, so being in two places at once isn't cool.

Can we do this ONLY for the website? The email is a Google AFYD account, so the email is working fine and the company owner is adament that email can experience zero downtime while the web move over.

please visit my question about how to migrate the email as well https://superuser.com/questions/93012/how-to-change-web-host-and-have-minimal-downtime-for-email


I wouldn't worry about the TTL stage.

Personally, I would do it like this, and as long as you do it in order - you can do it on the same day.

  1. Make sure that the new host is working (You already said it does).
  2. Set up DNS records at new host, pointing all A records / Cnames to the new host(or independent provider - I like Everydns). Also set up any additional entries such as MX records.*
  3. Take a backup from the old host and import to the new host / move database and change the site to a single page that has a Meta-refresh tag to the IP address of the new site site.
  4. Ask old host to change DNS to point to the new host.
  5. Ask old host to change name server to point to the new host.
  6. Wait for a few days just to make sure that all caches have expired and you can delete your old account - however, it will be pretty much inactive anyway.

* After step 2, you may want to wait 30 minutes - it is not really needed, but if the host has any funky DNS failover or load balancing, you may want to give it time to do its stuff!

As long as you pre-populate the DNS at the new host (step 2) with all the required fields (such as the MX records of Google Apps For Your Domain) before you switch nameservers, there should be zero downtime as it doesn't matter which dns server gets queried, it will get the same result from both.


what about creating an additional subdomain for the NEWIP, to which the old site redirects? there should be no downtime at all:

  • newandshiney.yourdomain.com points to NEWIP
  • your webserver at NEWIP serves the same content to 'newandshiney.yourdomain.com' and 'yourdomain.com'
  • you create a index.html @ OLDIP with something like "hey, we moved to a new server. you will be redirected shortly" and put something like the following to the <head> section:

    <meta http-equiv="Refresh" content="2; url=http://newandshiney.yourdomain.com/" />
    
  • you could also just use the NEWIP instead of 'newandshiney.yourdomain.com' inside that 'url' statement, depends a bit on the nature (virtual domains?) of your new hoster though.

  • then just switch the dns entries to NEWIP. done.

users who got the OLDIP from their dnscache hit the new crafted redirection index.html. users who got the NEWIP just hit the new servers.


Be aware that some ISPs, notoriously including Cablevision, ignore TTL and will cache your DNS entry for up to several WEEKS. You may wish to keep both sites operating in parallel for a while.