We have hosted a site on a particular data center. Now we would like to change it to another data-center.

What is the best way to migrate my web-server, and what is the correct way to update my DNS records. Also, how much time would it need before my domain was reliably pointed to the new data-center.

5 Answers 5


Disclaimer: I hate to be "that guy" right now but: If this is a critical website (e.g., makes you money), get some professional help please.

Depending on the type of site, this could be a very involved process. Best case scenario, it's a plain static HTML website. Even then, you'd still need to configure web server. If it is a dynamic website, you would need to configure a database and make sure the environment includes all the packages required by the website.

Also, if this is a production website, you'd want to schedule the proper outage.

Okay, now that I got that out of the way...

The DNS change is relatively simple. You'll just need to change the A record to point to the new IP address. We cannot provide you with exact instructions since that would depend on your DNS provider. However, this is a fairly common task so it should not be difficult.

One thing to keep in mind is the TTL (time to live) setting for your domain. This specifies how long the record for your domain should be cached (I emphasize should because that is up to the implementation of your visitors' DNS resolvers). You should keep that in mind when scheduling the outage.

To look up the TTL in Linux/Mac/Unix-like:

$ dig example.com

Once upon a time I had to do this for what was at the time the fourth busiest e-commerce site in the UK, when we brought a new internet connection into our data centre. Some time before the cutover, we lowered the TTL on the A record to 600s. We also agreed to keep the old pipe active for some time to come, so I put up an old desktop box running a stub apache on the old IP address just to log requests that came to the old site. I wish I'd kept the actual apache logs, but I still have a pretty good memory of the results of the test, which are real-world data, though some years old.

Many requests stopped coming in within 600s.

A substantial number, perhaps 10% of our traffic, did not. So at that time I can say that perhaps 10% of ISPs did not honour a TTL as low as 600s.

Nearly all the traffic had stopped within 48 hours.

Some traffic continued for as long as 6 weeks, when I got bored and turned the stub apache box off.

So if I had any recommendations to make, number one would be to echo Beaming Mel-Bin with "get professional help". Number two would be to make sure that your whole application works when accessed by IP address as well as domain name, and put up a stub server on your old IP address which does HTTP redirects page-for-page to the new address. Number three would be to make very sure that your clients know about the move well before it happens, so you don't get flooded with calls about "your website is down" (which really mean "my ISP is cheap and ignores TTL records"). Number four is to do the cutover out of hours.

  • This doesn't mean that ISPs' DNS servers don't honour TTLs. After all, they do. There's no caching DNS proxy server software that doesn't expire records. What it very probably means is that you have users who are using the buggy WWW browsers (Step forward, Netscape Navigator 3.x, Mozilla, et al..) that think that they can hold on to the results of gethostbyname() indefinitely.
    – JdeBP
    Jan 20, 2012 at 16:29
  • I agree that it doesn't mean they don't - you provide an excellent alternative explanation. But the existence of the alternative explanation doesn't mean that it's right, either. I have spoken to DNS admins at big ISPs before who've unashamedly admitted to me that they have hacked their DNS servers to ignore small TTLs, to minimise the number of lookups they have to do, and thus improve response.
    – MadHatter
    Jan 20, 2012 at 20:15
  • It's most definitely right for the 6 weeks case that you are ascribing to this. I repeat: There's no caching DNS proxy server software that doesn't expire records. Not even the ones that I've written or have published patches for. Non-expiry behaviour is always to be found somewhere on the application side of the proxy DNS server.
    – JdeBP
    Jan 22, 2012 at 11:15
  • J, I hear you, and I'm sure you're right about early browsers and appalling cacheing. But you can't know for certain that no-one has hacked their DNS server to do that, any more than I can know it's not application-side - that's the joy of free software. In any case, it's irrelevant to the OP, who will see the problem from clients whether it's their application or their ISP's server that have decided to wrongly and enthusiastically cache the record.
    – MadHatter
    Jan 22, 2012 at 20:40

@dannymcc has a good suggestion here. Speaking from experience, the following is a suitable and reasonably fault tolerant way to move your site:

1) backup the setups (files, settings, databases etc.) from your old data-center

2) move a copy to your new hosting. Setup your web server on the new server as if it is already using the live domain

3) hard code the hosts file on your local machine so that your domain points to your new server's IP (see http://www.techrepublic.com/article/keeping-your-sanity-with-etchosts/5033406 for Linux and entry about Static Clients on this page for Windows http://support.microsoft.com/kb/309642)

4) once you are sure that you're looking at the new server for your domain on your local machine - that is, you are forcing your local computer to resolve the domain to your new server - test that the site is working properly. HINT - hard code a piece of text into the page on the new server like "This is the new server" so you can be absolutely certain you are looking at the correct server

5) once you're certain that you're looking at the new server and everything is working correctly, you can start editing the zone entries (specifically the A-record) for your domain. You can use the NSLOOKUP command to find out where your nameservers are. Often they are bundled with your domain registration, but for advanced setups, this may not be the case. More often than not you will get some sort of web based editor for changing these - if you need to update it over a command line for something like BIND, I recommend you get someone experienced to do it

6) edit your website A-record (or other records as desired) so that they point at the new server. It will take some time for the DNS to resolve for everyone, and until you're sure that everyone is being redirected, I'd suggest leaving both copies up (you could check the server logs of the old webserver to see if it is still receiving significant traffic). It's difficult to say how long this will take, but my guess would be between 8-36 hours.


If your domain names are configured how they should be they will have two name server (NS) records. Such as ns1.datacentre.com and ns2.datacentre.com.

Once you have copied/moved the data from the old datacentre to the new one you should edit your hosts file so you can preview the new datacentre by entering the domain name in your web browser (Google is your friend).

Once you are happy that the new datacentre is configured correctly you then need to alter your name server records on the domain name(s).

Once the domain name points to your new datacentre it may take up to 48 hours for DNS propagation.

Good luck.

  • can you explain more on this "Once you have copied/moved the data from the old datacentre to the new one you should edit your hosts file so you can preview the new datacentre by entering the domain name in your web browser" .
    – Vidya
    Dec 4, 2011 at 16:49
  • Well you will need to transfer all of the data from the old datacentre to the new one. Once that's done you will only be able to test the new datacentre by using the public IP address. Do you have more than one website on the new datacentre?
    – dannymcc
    Dec 4, 2011 at 16:50
  • Yes we have more than one website . Does that make a difference ?
    – Vidya
    Dec 4, 2011 at 17:03
  • 1
    Yes, it means you will need to edit your computers host file in order to preview the websites on the new servers.
    – dannymcc
    Dec 4, 2011 at 18:36

It will normally take 24-48 hours to resolve the DNS. If you still cant browse your site within that time, you need to contact your registrant. :)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .