Moving a domain to a different server (2/3)
February 24th, 2007 by Joost SchrierThis is the second installment (of three) of a series about moving the hosting for a domain name to a different server. For some reason we still hear from clients that they couldn’t see their website or get their emails for days because the hosting of their website was changed. This does not have to be the case!!
This installment is specifically for those brave souls that try to understand how they should set this up for their clients. These are the on-line warriors that call themselves systems administrators. Well…., aspiring systems administrators because an educated systems administrators would start jawning after the third paragraph.
When you do this for the first time with a (relatively) simple website you probably have the following situation. Your website is hosted on a server, your e-mail is hosted on a mailserver owned by your hosting provider, the nameserver has an A-record which points to the webserver and an MX-record which points to the mailserver and the WHOIS database contains a reference to said nameserver.
When you change the hosting you have to go through the following steps:
- Get the hosting set up at your new provider (website and e-mail addresses)
- Ask the hosting provider about the new nameservers
- Change the nameservers at the registrar
- Make sure that no e-mails are left on the old server
- Cancel the old hosting
Setting up hosting at your new provider
Usually setting up new hosting for your domain is pretty straightforward. You choose the provider (amongst the millions that populate the internet), you pay them and they send you an e-mail with usernames, passwords, IP-addresses and general instructions.
When you set up your hosting at the new provider it is best to use the nameservers that they specify. The reason for this is that it can be pretty daunting to work with settings on nameservers and they will have set it up generically and workable for your needs.
With this data you can upload the website to the new webserver. When connecting to the new server through FTP make sure that you use the IP-address of the new server, because the domain name still points to the old server. So if you use ftp.domainname.com as the name for the ftp-server you will reach the old server instead of the new one. Do not worry if the new hosting setup is on a shared/virtual account, the username and password tell the server where it has to send you when you upload your files.
One problem with shared/virtual hosting is that it is difficult to check your website and see how it behaves on the new server because when you type in the domain name you get the old site and when you type in the IP-address you get a generic page of the webserver. You need the domain name coupled with the IP-address to really check it. Especially if you have dynamic, server side content in your website this is of critical importance.
This coupling can be done by adding a line to the so-called hosts-file on the computer you are working on. The first thing your browser does when you type in a domain name is to check in this hosts-file if the domain name is mentioned there. On Windows XP you can find this file in the windows directory: C:\WINDOWS\system32\drivers\etc. You can just open the file with Notepad and ad a line like this: 111.0.111.0 www.domainname.com. Save the file, open your browser and type www.domainname.com in the address bar. You will now see the new website. This, of course, only works on the computer on which you have changed the hosts-file.
When everything works well you can move on to adding e-mail addresses to the domain name. Nowadays you can usually do this yourself through the hosting provider’s back-office. To minimize the amount of work for the client it is useful to use the same usernames and passwords as you had on the old mailserver. Once this is set up you can check the addresses by setting up new accounts in your e-mail application (Outlook, Thunderbird and such). When you do this make sure to use the IP-address for the POP-server instead of its name because the name still points to the old server.
Finally; it is wise to check the setup of the new hosting on some more abstract levels. You can do this by using the tools at www.dnsstuff.com and, even more useful in this case, www.dnsreport.com. The tool at dnsreport.com allows you to test the setup of your webhosting. When you type in your domain you will get a detailed report about your servers. The URL for the report will look something like this www.dnsreport.com/tools/dnsreport.ch?domain=www.dgfmedia.net. This report will be about the setup of your current (old) hosting. By adding one of the nameservers of your new hosting to the URL you can also see the report for the new hosting setup. You can do this by adding “&server=your.new.nameserver” to the URL. This is a setting that tells dnsreport.com to look for the records at your new nameserver instead of the ones that the registrar tells it to look at. This tool is really invaluable because it allows you to test your setup and minimize stress once the public can actually see the website in its new location.
Now you should be ready to change the nameservers at the registrar.
Changing the nameservers at the registrar
When you have registered a domain name you are given a username and password to log into your account at that registrar. (Editor’s note: this is true in most IT-minded countries. In the less so countries you need to fill out forms, send these to the registrar and wait until they find the time in their busy schedule to actually change the nameservers by hand.) When you log into your account you can change the nameservers there. Here you can just fill in the nameservers, at least two, and their IP-addresses (the IP-adresses is not always necessary).
The moment you hit submit and try to check your new hosting you will see that nothing has changed. The reason for this is that when you changed the nameservers you have changed a record at that registrar, it is not yet changed in the big registrar-database and you can be sure that your local dns-server does not know anything about it yet. The change first needs to be propagated through the internet, provider caches need to be emptied because even today it does take time to notify the whole world about a change. This propagation usually takes somewhere between 24 and 48 hours. NB: when you run the report at dnsreport.com again (and don’t add the server= line) you will see that they are more up-to-date than anyone else.
Because of the time it takes to propagate this change through the internet it will happen that some people can already see the new website while others still see the old website. Besides this, and this is even more annoying, while the propagation is ongoing e-mails will be delivered to the old server and to the new server depending on whether or not the network of the sender is already aware of the change or not. This means that the client will have to download his e-mails from two locations for two days. More about this in the next installment.
When everything is done you can check on the old server to see if there are still mails there and if the answer is no, the account can be cancelled.
<< 1st installment 3rd installment >>
