Printer-friendly version

Alas, a good hosting company is hard to find.  All too often, we find that the proverbial grass is greener in another pasture, and it's time to move.  But a modern Web site is a dynamic thing, being edited by lots of people.  How do you make sure that the most recent version gets copied?  Here are the steps I've developed:

1. Set up the control panel on the new site to match the old site.  Start with the domain names, subdomains, SSL certificates, and databases, leaving the other steps for later.  This is a good time to ask the client (or your own users) for any passwords to email accounts and maling lists, since people can sometimes be slow to get you that information.
   
2. Make a preliminary copy of all the files and databases, for testing purposes.  The easiest way to do this is from the command line:
   1. (on the old site) tar -czf files.tar.gz public_html
   2. mysqldump -u username -p --all_databases > databases.sql
      
   3. ftp newIPaddress
   4. put files.tar.gz
   5. put databases.sql
   6. (on the new site) tar -xzf files.tar.gz
   7. mysql -u username -p < databases.sql
   If you don't have access to the command line,use an FTP program like FireFTP to download the entire public_html directory to your computer, and then use phpMyAdmin to export each of the databases to files on your computer.  Then reverse the steps to put the files and databases on the new server.
   
3. Download a copy of the files.tar.gz file (from step 2.1 above) to your own computer, and unpack it.  You will use this in a later step.  If you don't have access to the command line, use an FTP program like FireFTP to download the entire public_html directory to your computer.  (This may take some time.)
4. Change the hosts file on your own computer so that the domain name points to the new server's IP address.  This helps greatly in testing, because you can use the domain name in your browser instead of an IP address.  Some software's clean URLs and other features will not work properly when accessed with an IP address.
5. Change the configuration files on the new site to accommodate the new database names and usernames, since these usually differ from one host to the next.
6. When you are satisfied that the site is working properly, notify the client (and/or your own users) of when you intend to move.  Try to pick a low-traffic time of day or a weekend -- study your access statistics.  Allow at least 3 hours of uninterrupted time to make the move final.  This is also a good time to notify the client (and/or users) of the Webmail addresses where they can get their mail on the old and new servers -- this means IP addresses, since the domain name will point to only one of the two places.
   
7. Before the time arrives, finish copying any control panel settings you haven't already copied.  This includes email accounts, forwarding addresses, and mailing list settings (including their membership rosters), but not the archives of mailing lists -- generally you don't have access to these and have to ask support.  This is a good time to ask.
   
8. At the appointed time, lock down the site from further editing.  In Drupal this is quite easy -- just go to Admin -> Site Maintenance and set it to Off-line.  In PmWiki it is more difficult to do... probably the easiest way is to edit the template or SiteHeader page and make a prominent note saying not to make any changes, and just rely on people to do the right thing.
9. Use a good FTP program with a synchronization feature, like FireFTP, to connect to the old server and synchronize your copy of the files, downloading only the files that are new or have changed.  Then connect to the new server and synchronize again, this time uploading only the files that are new or have changed.  This is much quicker than downloading another complete copy of the site.
10. Export and import the databases again, either using the command line steps above or phpMyAdmin.
11. Repeat step 5 above to correct the usernames in any configuration files.
12. Change the DNS (domain name server) entries for the domain name(s), to point to the new host.  Be aware that the change will take some time to propagate across the Internet.
    
13. Unlock the site on the new server, undoing any changes you made in step 8.
14. Remove the lines from your hosts file (from step 4) so that you see what others will see.

You may ask, why copy the site twice instead of just once?  Because something unexpected will almost certainly go wrong, usually at step 5, and you want it to happen before you have set a deadline for the move, not after.