Migrating websites between Virtual Private Servers

So I recently found myself needing to move websites from one VPS to another.   In this case it was the same provider but different datacenters within the US.  While I was contemplating options I discovered a few rather simple tricks and thought I would share them here.  My research didn’t turn up any complete post on migrations (though a few came close) and I wanted a somewhat comprehensive guide.  As always this advice is given AS-IS and I cannot be held responsible if you destroy your data, bork your servers, or get your account suspended by your host.

Anyway let’s get started.  This post assumes you are moving between similar platforms and architectures.  I’m going from CentOS 6 to CentOS 6 both are x64 platforms.  If you are trying to migrate between dissimilar platforms (Debian to CentOS) or architectures (x86 to x64) there is a good chance these instructions will not work.  I’m also assuming you have installed all the correct packages on your new server.  You can do a “yum list installed” in your source server to see what all you have installed.

The first step is an initial sync of your files.  Depending on the size of your web root and the server’s Internet connections this might take a while.  I suggest you start this before bed then check it in the morning.  There is no need to worry if it fails as we will be running this  multiple times.  We are going to use rsync for the entire file sync process.  The command you need to run is:

rsync -avzhe ‘ssh -p 22222’ root@OLD.HOST:/var/www/ /var/www/

This command needs run from the DESTINATION SERVER.  If you are looking into the specifics of the rsync command please see here.  The only thing I will note is the number after the -p is the SSH port number.  22 is the default.

We can run this command as many times as needed as it will only bring across changed files or those that didn’t exist the first time.  If the initial sync fails simply run it again.  Now we need to move over any config files, this is easiest to do with rsync as well – again run from the destination server:

mv /etc/httpd /etc/httpd.old
rsync -avzhe ‘ssh -p 22222’ root@OLD.HOST:/etc/httpd/ /etc/httpd/

The first command moves the existing httpd directory to a backup location while the second brings over all the configs from the old server.  There are a handful of directories you will want to run this on including, but no limited to:

Once you have done this it’s time to pick the migration time and run a few more commands.  I choose early on a Sunday for this final migration.  Shut down the Apache service on the source server.  Time to migrate the MySQL databases.  This command works nicely but need run from the SOURCE SERVER:

mysqldump -u root -pPASSWORD –all-databases | ssh -p 2222 root@NEW.HOST ‘cat – | mysql -u root -pPASSWORD’

Of the PASSWORD variables listed there the first is the MySQL root password of the source machine, the second is the MySQL root password of the destination machine.  You will be prompted for the main root password of the destination machine when you execute this command.   The number after the -p, as before, is the SSH port number.   As with the rsync this command may take a while.  Now time to run the final sync on the web root.  Same command as before:

rsync -avzhe ‘ssh -p 22222’ root@OLD.HOST:/var/www/ /var/www/

Assuming not much time has passed between the first time you ran this and now it should run fairly fast. 

Moment of truth, shut down all web service on the SOURCE server: MySQL, httpd, postfix, etc.  Start all services on the DESTINATION server.  Then change over your DNS to point to the new server.  Assuming everything came up as expected you should be golden!

Test all the sites you had running on the old server paying close attention to things like SSL and 301 redirects handled by the .htaccess files. 

You have now migrated to a new server!  While this seems like a lot of steps when you actually dig down into it there really isn’t much here.  Feel free to leave a comment with your experiences or any questions/comments you may have. 

Leave a Reply

Your email address will not be published. Required fields are marked *