Originally published at www.newsforge.com
The Web site hosting business has become more competitive in recent years. If you can find a better hosting deal, you may be able to save money by switching hosting providers. But what's the best way to move your Web site? What if you have a virtual private server (VPS) hosting several domains? What about PHP and your SQL data? The thought of moving may be daunting, but moving servers is not difficult if you plan properly. Here's how.
A complete migration involves transferring the site data itself, meaning all the HTML and possibly PHP and MySQL files and CGI programs. You also need to modify the Domain Name System (DNS) information for the site and for the routing of the site email. DNS holds information that translates IP addresses to human-readable domain names. For Web site migration, the two important DNS records are the address (A) record, which tells the browser the IP address of the Web server, and the mail exchange (MX) record, which tells mail servers how to route the email.
When you migrate your Web site to another hosting provider, you need to update DNS to point browsers to the new location of your site. However, it can take as long as 48 hours for DNS updates to propagate to all DNS servers on the Internet. Part of your planning will be how to deal with that delay.
Often your domain name has been registered via a third-party domain name registration company. When you move the site, your domain name company remains the same, and only your Web hosting company changes. If your domain name originaly came with hosting, you may need to contact your old hosting company to see if you can separate the hosting package from the domain name.
Preparation
The keys to a successful move are planning and preparation. Before the move you should warn your users or customers of the forthcoming upgrade. Prepare a "server down for upgrade" page for your old site. Note the IP addresses of your new and old servers; these will come in handy when DNS is still in flux.
Decide when to upgrade, meaning when your server is least busy. If you have site statistics, use those to determine the best time. To reduce down time, it is best to make the DNS changes several hours before you actually move the domain. As long as your mail server is running on the new server, you won't lose any email messages. If you have a static site, you can copy over the data before you switch DNS and no one will ever know your hosting provider changed. For a dynamic site you can out a skeleton site on your new server until you make the full move.
The DNS changes you need to make involve updating the MX and A records to point to your new server. To do that, you need to access the control panel provided by the domain name registration company from which you obtained your domain name.
The new MX record will need to point to the new server. Like A records, MX records can take a while to propagate through the Internet. To avoid mail loss you will need to check your old mailbox at least once a couple of days after the move. You will also need to use the IP address of the old mail server rather than its domain name, as you won't be able to rely on mail.domain.com to check the old mailbox, as that will point to your new server. Depending on how much control you have of your old server, you could shut down the mail server after modifying the MX records, in which case incoming mail would queue up until the new mail server is running, at which point it would be delivered without problems.
The move
Once you've handled the DNS information, it's time to tackle the data itself. HTML and PHP files aren't hard to move; just use a good FTP program and copy the data from one server to the other. If you have SSH access to both of the servers you can copy the files directly. If you don't, you will have to download the files to a local machine and then upload them to the new server.
Moving databases is a bit more complex. Assuming you are using MySQL, there are several ways to copy over the data. One is to do a dump of the data into a file and then copy that file to the new server and populate the new database. To do this you use the mysqldump command:
$ mysqldump -p -u username mydatabase > mydata.sql
Once copied onto the new server your can populate your new database with the mysql command:
$ mysql -p -u username mydatabase < mydata.sql
If you don't have SSH access to your servers you won't be able to use these MySQL commands, but you can still use a tool such as phpMyAdmin that handles MySQL administration over the Web. phpMyAdmin has excellent dump and restore features, though for the restore there is a maximum upload file size of 2,048KB. You can use compression to maximize your chances of squeezing all of your data into 2MB. [what if you have more than 2MB, as many of our readers will? - Lee, I have altered the next paragraph to clarify this]
If you lack SSH access and you have too much data for phpMyAdmin to handle, look into a MySQL synchronization tool called SQLyog Job Agent (SJA).
If all else fails you will need to ask the support team of your old hosting company to dump your database for you. Then you will need to ask the support team of your new hosting company to populate the new database.[Lee, I have added this paragraph in case readers don't have ssh, can't use phpMyAdmin and can't use SJA.]
If you have a site with dynamic data, such as an e-commerce site, you need to make special provisions for the DNS update delays. As the DNS changes propagate through the Internet some people will see your new site and others your old. This could cause problems for you. Imagine a customer placing an order on your old site after you have moved all the data over to your new site.
There are two [different] ways you can deal with this problem. [Lee, this is an either-or] First, stop taking orders on the old site once you have started the move. At the checkout stage display a polite notice asking customers to come back in a couple of hours, after which they should be taken to the new site. If you don't have that kind of control over your site then the best thing is to close down the old site by replacing its index.html with a notice saying the server is down for upgrades and will be back soon. An alternative solution is to use a synchronization tool like SJA to make sure any changes made on the old site get propagated to the new one.
Finally, watch out for incompatibilities between the software on your old server and that on the new. Try to make sure that any difference in versions of crucial software like MySQL and PHP won't cause any problems.
Virtual private servers
If you host a VPS installation then you probably have several domains to migrate. The problems are the same, but there is more work to do. If you have a VPS you should warn your customers in plenty of time about the upcoming move. Call it a server upgrade, as this will cause less worry.
An advantage of having a VPS is that you have more control of your sites. You probably have SSH access and you can do things like shutting down the mail server during the transition. However, if you are hosting domains for others, then there is the problem of passwords. When you move to the new server you will need to re-create domains and user accounts, but you won't have access to the passwords set by your customers. Generally you will need to issue your customers new passwords. Again, plenty of advanced warning will help ease the pain.
If your VPS uses Plesk 7 Reloaded then migration becomes a lot easier. This software includes a great (though still experimental) tool called the Migration Manager that supports migrating from remote servers using Plesk 2.5.x, 5.x, 6.x, and 7.x, as well as Confixx 2, Ensim 3.5.x, and cPanel 9.
To use the Migration Manager you need to enter the remote host address (it is best to use the IP address), the login name (normally root) and the password. After that you set the remote system type (Plesk, cPanel, etc.) and click Next. The Migration Manager will then send an agent to the remote server and offer you a list of domains and clients on the remote server. If you migrate a client it will bring over the client data (like username and password) and all the domains belonging to that client. If you import a domain you will have to have a client account ready on the new server to take ownership of the imported domain.
Although experimental, for standard cases Migration Manager should work well. In a recent real-life migration, 95% of the domains [I moved for a client] migrated without a problem. There was one domain that had more than 100 subdomains that failed; They had to be copied over by hand!
Conclusion
When moving servers you need to keep downtime to a minimum. If you plan properly your users may not even notice that you have switched servers. If possible, perform a trial run of the actual move. No one will see your new site because you won't update DNS yet. To enable you to see your new site, edit the /etc/hosts file on your client and add your domain name (including the www) with the new IP address. You should also restart your browser. Don't forget to remove this entry when you have finished experimenting.
Gary Sims has a degree in Business Information Systems from a British university. He worked for 10 years as a software engineer and is now a freelance Linux consultant and writer.