Leaving your current web hosting provider for the cloud experience may feel rather scary, but in reality, it is a liberating experience.<\/p>\n
Just think of all the freedom you gain to run your web services your way: the ability\u00a0to\u00a0use any\u00a0DNS provider of your choice, any certificate authority (such as, most notably, the disruptive force of Letsencrypt),\u00a0install software to your heart’s content, scale up and out on demand, in other words, be\u00a0in charge of your own services and infrastructure. Here is a quick tutorial on how to\u00a0make the leap.<\/p>\n
<\/p>\n
There are quite a few important\u00a0considerations when migrating a web site.\u00a0Are 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\u00a0web server software (for example, from Apache to NGINX), changing the SAPI, upgrading the PHP engine to take advantage of improved security and higher\u00a0performance, 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:\u00a0High-Stakes, High-Security LEMP Setup: Nginx with MariaDB\/MySQL, and PHP 7.x on CentOS 7 (RHEL\/Fedora) with SELinux<\/a>.<\/em><\/p>\n One of the most important questions is how to minimize the downtime. The answer is: by\u00a0being smart about the DNS switch from the old to the new server.<\/p>\n Backup your CMS “as is” on\u00a0the current host. Once you have a backup,\u00a0update all relevant software on\u00a0both systems, then run a backup again.<\/p>\n If you are running on xfs,\u00a0btrfs, ext3, or\u00a0ext4 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<\/a>:<\/p>\n As soon as\u00a0your 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\u00a0adjust SELinux labels on the file system and allow access to TCP sockets.<\/p>\n 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<\/a>. It can even make replacements (for example,\u00a0replace the\u00a0old\u00a0host name with a new one) in the database if needed.<\/p>\n Now this part is tricky. You said you wanted to minimize downtime (and who doesn’t!), here is how to do it:<\/p>\n All your users who were signed in must sign\u00a0in again, obviously, but other than that, the downtime should be minimal.<\/p>\n Here is the snippet to enforce a\u00a0host name\u00a0in the wp-config.php file of your\u00a0WordPress installation to define how WordPress identifies itself; should you need it, it’s very handy:<\/p>\nStep 1. Make\u00a0a backup followed by an update, then another backup<\/h3>\n
\nQuick Tip: Freeze the File System<\/h6>\n
#
xfs_freeze -f \/myxfs<\/code><\/strong> # # ... Take snapshot of file system ... # xfs_freeze -u \/myxfs<\/code><\/strong><\/pre>\n
\nStep 2. Install WordPress on the destination host<\/h3>\n
Step 3. Migrate your data: uploads, themes, plug-ins, and\u00a0database(s)<\/h3>\n
Step 5. Adjust the domain name which WordPress identifies with<\/h3>\n
\n
define('WP_HOME','https:\/\/www.yourdomain.tld\/somedirectory');\r\ndefine('WP_SITEURL','https:\/\/www.yourdomain.tld\/somedirectory'<\/a>);<\/pre>\n