How to migrate your web services from any hosting provider to AWS

Leaving your current web hosting provider for the cloud experience may feel rather scary, but in reality, it is a liberating experience.

Just think of all the freedom you gain to run your web services your way: the ability to use any DNS provider of your choice, any certificate authority (such as, most notably, the disruptive force of Letsencrypt), install software to your heart’s content, scale up and out on demand, in other words, be in charge of your own services and infrastructure. Here is a quick tutorial on how to make the leap.

There are quite a few important considerations when migrating a web site. Are you switching from a control panel-enabled hosting to a “raw” infrastructure-as-a-service offering? (In case of AWS EC2, the answer is yes; in case of AWS Lightsail, both yes and no.) Are you also changing your web server software (for example, from Apache to NGINX), changing the SAPI, upgrading the PHP engine to take advantage of improved security and higher performance, and/or possibly the database server in the process as well? Here is a comprehensive tutorial on how to set up your new server on Linux with NGINX, PHP, and MySQL/MariaDB: High-Stakes, High-Security LEMP Setup: Nginx with MariaDB/MySQL, and PHP 7.x on CentOS 7 (RHEL/Fedora) with SELinux.

One of the most important questions is how to minimize the downtime. The answer is: by being smart about the DNS switch from the old to the new server.

Step 1. Make a backup followed by an update, then another backup

Backup your CMS “as is” on the current host. Once you have a backup, update all relevant software on both systems, then run a backup again.

Quick Tip: Freeze the File System

If you are running on xfs, btrfs, ext3, or ext4 and happen to be paranoid, you probably want to make sure no data is lost in the course of a backup. The solution is to freeze and unfreeze the file system as per Oracle’s directions found here:

# xfs_freeze -f /myxfs # # ... Take snapshot of file system ... # xfs_freeze -u /myxfs

Step 2. Install WordPress on the destination host

As soon as your web server with PHP and MySQL/MariaDB is up and running, wget WordPress and follow the usual installation instructions. On systems with SELinux, you will need to adjust SELinux labels on the file system and allow access to TCP sockets.

Step 3. Migrate your data: uploads, themes, plug-ins, and database(s)

You could dump the databases and rsync the servers, and many people do just that. However, there is an easier way, try it and it will make your jaw drop: the All-In-One WordPress Migration Plug-In. It can even make replacements (for example, replace the old host name with a new one) in the database if needed.

Step 5. Adjust the domain name which WordPress identifies with

Now this part is tricky. You said you wanted to minimize downtime (and who doesn’t!), here is how to do it:

make sure that the TTL for your domain is as short as possible (depending on your current setup, you may need to wait a couple of hours for the new setting to propagate so that it will be respected when you perform the DNS switch; you will reverse this setting afterwards),
set up WordPress with all your content on your new server using a temporary host name such as www7.yourdomain.tld by enforcing the name switch the the wp-config file of your site’s configuration (see below for details),
verify that everything is working on the new (temporary) host name,
change the web server configuration on your new server to include your usual main (SEO-ranked) hostname www.yourdomain.tld so that when you switch the DNS to the new server, it will answer requests (up to that point, requests won’t be routed so the server can only respond to the temporary host name),
remove the lines that enforce the temporary name in wp-config so that WordPress will continue to identify with its usual, SEO-ranked host name (if you made replacements in the database, you should probably reverse them; the amazing All-In-One WordPress Migration Plug-In can take care of that for you by exporting and re-importing the database on the new server with replacements in place),
at this point WorPress isn’t working correctly on the new server (links will be redirecting to your old server that is receiving requests on your standard host name) but that doesn’t matter, you are ready to switch the DNS from the old to the new server.

All your users who were signed in must sign in again, obviously, but other than that, the downtime should be minimal.

Here is the snippet to enforce a host name in the wp-config.php file of your WordPress installation to define how WordPress identifies itself; should you need it, it’s very handy:

define('WP_HOME','https://www.yourdomain.tld/somedirectory');
define('WP_SITEURL','https://www.yourdomain.tld/somedirectory');

If hard-coding the “installation identifier” is not appealing to you, you could enforce an update of the host name by putting a directive into your theme’s functions.php file, reloading the site a couple of times, and removing these once the change has taken place (check the Codex for more details):

update_option( 'siteurl', 'https://www.yourdomain.tld/somedirectory' );
update_option( 'home', 'https://www.yourdomain.tld/somedirectory' );

Just remember to remove the two lines from your functions.php when they are no longer needed (which is, as soon as the update takes place).

Step 6. Reconfigure DNS

Now is the time to point the DNS configuration away from the old instance to the new server instance. Verify that the site is running (should it need some major troubleshooting, reverse the last DNS change to temporarily revert to the old server). When you are done, shut down the old server so it will not be serving requests.

You may want to increase the TTL in the DNS configuration for your domain to reduce unnecessary expenses (you won’t be migrating anything anytime soon, so your setup won’t be changing).