When a website relaunch requires a migration, there’s one really iffy period that’s always given me the most trouble. You’ve drawn and designed, built mockups and prototypes, coded your site on a local server and even pushed it up to a demo subdomain on your own site. After all this, though, there’s still one more trigger that needs to be pulled: pointing DNS records at your new hosting.
It is possible to just put the new site on the same hosting account, but that does introduce it’s own problems. More often than not, we find ourselves setting up the new site on a new server and swapping out DNS records once we feel ‘confident’ that everything is ready to go.
When you’re just starting out, going live with a website has a tough learning curve amongst IP addresses and nameservers, FTP accounts and command line interfaces. You could get everything working just perfectly, pull the trigger, and realize that you forgot to migrate the MX records or all of the email accounts. That’s why there’s no substitute for a good checklist, something you craft out of the years of bad mistakes.
One tool I want to add to your migration toolkit is hosts.cx: the website previewer. This website takes a lot of the guessing game out of migrating servers. To fully understand the value of hosts.cx, it helps to understand DNS records and what they are.
Defining DNS Records
DNS stands for Domain Name Service, and its the technology that allows us to write facebook.com instead of 18.104.22.168 when we want to see cat videos and our relatives’ political opinions. If that string of numbers punctuated by three periods looks familiar, then you have some idea what an IP address is. An IP (or Internet Protocol) address is much like your home address in that it refers to a very specific physical location of a server or set of servers.
When we want to put our website out into the wild, we host it on a machine and we label it with a domain name that we own. We might call it “example.com”. Then we set up our domain registrar (usually the company we bought our domain from) to send anyone who types in our domain name to the IP address of the machine that holds that website. Their computer pulls up the “example.com” website stored at that IP address.
This ensures that when the user types in a URL, they get the correct website. While I could create my own facebook.com on a server, nobody who types in facebook.com would see it, because the DNS records don’t point to my IP address, they point to the servers run by Facebook.
Altering DNS Records
After we’ve migrated all of the folders and files, the disks and databases, the next step is usually to point the domain’s nameservers to our new server or hosting company. But this is where a lot of issues can fall apart. Did all the files transfer correctly? Did I miss any subdirectories? Did I bring over the correct databases and will the web pages be able to read from those databases? All of these questions and more run through your head when you pull the trigger and swap out those nameservers to your new location.
But even changing nameservers is not instantaneous. In fact, DNS records don’t just exist with our domain registrar. Whenever we visit a website, our browser caches, or stores, those records locally on our computer for a predetermined set of time. Instead of asking the domain registrar every time we want to visit our website, the computer consults your local list of DNS records and pulls up the appropriate IP address.
Because these records can be altered, this set-up has a few interesting side effects. In order to preview a website on a new server, we can manually edit our local DNS records to pull up a different IP address. Meaning, we can trick our computer into giving us a preview of our new website before we actually make the transfer.
It’s worth noting that a negative side effect is that this makes it possible for hackers who have access to your computer to spoof DNS records, tricking you into visiting malicious websites. As always, you should follow all best practices on your computer as well as with any sites you plan on hosting.
Using local DNS settings to preview a new IP address has many shortcomings. It’s time consuming, it’s never comfortable messing around with system files, and you can’t share your results.
Instead, simply enter the server IP address and the domain you stored the site under and host.cx gives you a sharable URL that allows you, and anyone else with the URL, to preview your site. Coming from a world of manually editing host files through the terminal, it feels like there should be more steps, but this really is it.
Hosts.cx was a real game changer for me. Having recently migrated a number of sites to a new hosting company, a process which I hope to write about in the future, I’m seriously glad I discovered this before and not after. I build most of my sites on the open-source WordPress software, so the ability to make sure that pages were loading and database connections were working is priceless.