Sometimes servers need to move. Maybe you’re switching hosting providers, or you’ve got a box that’s dying and needs to be swapped out (and unplugging the one and plugging the other in isn’t viable,) or there’s some other situation where the… actually it’s not relevant that the server’s changing; it’s all about the IP address.
If a domain name like whatever.com is a server’s name, a server’s IP address is like its phone number. And once upon a time we had these things called phone books that would be delivered to every door in a city, and those books would have a list of names and numbers. You’d know you wanted to call Phoney McPhoneface, so you’d look up his name, find the number, and dial.
With servers, the role of phone book is handled by a system called DNS, short for Domain Name System (so you probably shouldn’t say “DNS System” any more than you should say “ATM Machine” but let’s ignore that I almost did it earlier in this paragraph.) It’s a simple service that takes a query with a server name, and responds with an IP address. There are different types of records and some other nitty gritty details, but they don’t matter as much here.
[Note that most of this is geared towards single-server websites or services. If you’ve got a cluster of servers behind a load balancer DNS generally doesn’t come into play, for example.]
So when you want to change the IP address of a server (let’s use the easiest use case that you’ve set up a copy of the box and it’s ready to go, but traffic is going to the old server right now,) you simply have to change the relevant DNS records, and future users of the box will get pointed to the right one. Easy peasey.
…Except when it isn’t. DNS entries are cached for a period of time. There’s a setting called Time To Live (TTL) which instructs the network how long to hold onto that address. This might not be honoured by every piece of the puzzle around the world, so you should have a plan to deal with lingering traffic, but that’s for another post. The key here is that once you change a DNS setting, it might take from a few minutes to a day (or more, in theory) for the new address to get out into the wild.
And on the flip side, if you need to change it back, there’s going to be a window where traffic is going to the new box before the change is noticed by everyone.
All of this leads to the first rule of new server testing: don’t test the new server by updating your DNS records.
For one thing, it’s inefficient (you have to wait for the change to make it to you before you can test things,) and there’s the potential for real user impact (other people may see the new box before you, and it’ll take just as long if not longer to point them back to the old one if there’s a big problem.)
Instead, you can test your new server locally by ignoring DNS altogether and simply telling your computer the IP address. For some server setups you can just type the IP address into your browser bar, but if it’s on a shared server that probably won’t work.
For those cases, you’ll need to edit your hosts file. This is located in /etc/hosts for Macs and Unix systems, and in /windows/system32/drivers/etc/hosts for Windows. And that’s on your local testing computer, not the server.
This file is a simple name/address lookup table. There should be enough example lines in there already for you to get the idea, but each line is basically just “servername IP” e.g. “whatever.com 192.168.1.1” (but, you know, with your hostname and new server IP)
You can confirm the change by pinging the hostname (e.g. “ping whatever.com”) from the command line/terminal. Your new IP should show up. I find it’s helpful to make a small visual change to the site I’m testing just to be sure, but that’s not necessary.
Once you’re satisfied that the new server is good to go, that’s when you should make your DNS change. It’s a good idea to remove your hosts file change now too in case you made a mistake with the DNS (by the way, you can also test your DNS changes with the nslookup or dig commands.)
I’ll be honest, this is pretty trivial stuff, but I recently had a client who was asked to change their DNS over to a new server and apparently nobody had tested it, because the new site was filled with errors, and when I pointed this out I was told that the admins couldn’t recreate the error until I changed the DNS, so maybe it’s not widely known. People also have a tendency to do whatever’s easiest for them, and their drivers are different than yours, so it’s important to ask with any change if there’s going to be downtime, and if there’s a way for that downtime to be reduced or eliminated.
Almost all of my client work involves taking on existing projects, so server migrations are pretty common during that handover. If you’ve got a server that needs a new developer, get in touch now to see how I can make that transition as seamless as possible.