Things to Remember When Migrating a Website
After undergoing a multi-site migration only to watch things crash and burn, I’ve come up with a checklist of what to remember when migrating a website.
For me, the move was from Slicehost to Amazon EC2. Slicehost is a great host, one of the few that give you absolute control of a virtual server for a reasonable price. Amazon EC2, however, gives you more reliability/redundancy, “pay-as-you-go” bandwidth/io pricing, and cheap/easy backups, for less. But this isn’t intended to be an advertisement of Amazon’s EC2 services.
Migrating websites is always an easy process until something goes wrong.
Note that I run a LANMP setup (Linux, Apache, Nginx, MySQL, PHP). The combo of Apache + nginx is great for performance and reliability, but technically adds an extra layer of “things that could possibly go wrong.”
Install
The basics: Apache, nginx, MySQL, PHP, SSH, VSFTPD, postfix, logrotate.
OS Level
Check file permissions and owners on everything
File permissions and owners don’t transfer over when copying files from one host to another. If you’re running a WordPress blog, wrong permissions or owners may prevent you from downloading/upgrading plugins or your WordPress installation.
Recreate cron jobs
Cron jobs allow you to automate scripts. They’re especially handy for PHP sites that pull data from other sources or need to continually crunch numbers. They’re also easily forgotten. Use the command crontab -e to view your cron jobs.
Recreate the same directory structure
If you’re copying your files straight from the source, this should be an easy one.
MySQL
Recreate the MySQL database and tables
Hopefully, you’re using a nice GUI like HeidiSQL that lets you export your entire database to another MySQL server.
Recreate the same MySQL users, with the same user permissions
Fairly self-explanatory. This is actually a great time to rename your old users to something more meaningful
Modify all PHP scripts to point to new MySQL server
If you aren’t using “localhost” in your mysql_connect statements, you may need to change your PHP database connection scripts accordingly.
Apache
Create virtual domain files in Apache
/etc/apache2/sites-available houses all of your virtual domain information, including locations of your websites (assuming you have multiple websites on one server)..
Enable the site in Apache
On Ubuntu, use the a2ensite command: sudo a2ensite blahblahblah.com. This creates a symbolic link from the sites-available directory to the sites-enabled directory.
Modify the apache2.conf file accordingly
Don’t forget to edit the standard Apache config file, namely apache2.conf in /etc/apache2.
Nginx
Change nginx.conf/proxy.conf
Like apache2.conf, the nginx.conf file stores all of your basic settings (what user to run as, number of processes to use, gzip compression, etc).
Other
Change DNS servers and A records
This is done at the domain level. Essentially, if you’re moving your website to a different webhost, you’ll need to change the name servers (“ns1.blahblahblah.com”, “ns2.blahblahblah.com”, etc) in the site’s WHOIS and change the A record to point to your new website IP address. This can usually be found in your web hosting control panel.
Test email sending
Easily forgotten. You may want to create and run a simple PHP script like this:
<?php
// test the mail server
if (mail('blahblahblahblahblah@asjkdhka.com', 'test subject', 'blah blah blah'))
echo 'mail sent.';
else echo 'sorry, there was a problem';
?>
Don’t forget to replace the first argument with your own email address, and check your spam mail (Gmail drops basic PHP emails into the spam folder).
Test everything!
Do a run-through of every website. Check your log files. And brush your teeth!
