I recently set up a new VPS, because there was a sale on an instance large enough to serve my needs (and then some) at a price point that I couldn’t ignore.
My old host was RamNode, and make no mistake, I’ve never ever had any qualms with RamNode – the customer service has always been above and beyond. If I was running a business on a VPS, I’d be quite comfortable using RamNode.
But I’m… not running a business. I host a few blogs, connect to IRC remotely, do some programming tests and things like that. I want a lot of reliability, to be sure, but my needs are really pretty light; I could probably get by with a small Linux box (maybe even a Raspberry Pi) on my home network, if I didn’t live in the boonies on a trunk that’s already saturated with my neighbors’ traffic.
So I’m migrating to SSDNodes. They were running a sale, like I said in the first paragraph, and how could I resist that?
That left actually migrating a few sites. The first site I migrated was AutumnCode, which is my actual primary domain. But that’s effectively a static site, and served mostly to confirm that I had nginx set up properly.
That left migration of the WordPress sites.
I’m a simple man; I actually set up each site to run on its own database, even though I could get by with a multisite configuration, so I needed to migrate each one separately (which served my purposes anyway; I could migrate the less important sites and validate that the migration worked, and work my way up to the “more important” sites, like the one you’re reading right now).
So first I backed up my NGinx configuration and my LetsEncrypt directory, as a whole. I then pushed all of those configurations to the new server.
I could have used the WordPress backup mechanism to move sites, I suppose, but I have some sites with a lot of media (images, etc.), plus that felt like a lot of work. What I ended up finding was a WordPress plugin, called Duplicator Pro. There’s a free version (Duplicator!) and it … works, but there are constraints for it.
Duplicator Pro was worth it, though. I got the cheapest version, because you can enable it and disable it per site.
It’s really easy to use. After installation and registration with a key, you create a “package” for a given site. A package consists of an archive (either a zip or a daf file) and an installer.php file.
You download those two files and store them. Then you create a database and a user for the site on the target system.
Next, you set up resolution so that you can refer to the new server by name – for me, that meant going to my desktop computer’s /etc/hosts file and adding an IP and a name. This means that the old server still works for anyone else on the Internet, but that I can work on the new server to install everything I need on it.
Now there’s some relatively easy work to do – copy the NGinx configuration file for the site into place (normally /etc/nginx/available-sites) and create a softlink in /etc/nginx/enabled-sites, along with making sure the directories for the sites exist. Then copy the package files into the HTML directory for the site.
After the directories are set up, restart NGinx.
You now actually have a “working site” although there’s nothing there that should be publicly available; installer.php might be (if you named it that, and I didn’t) but nobody else knows about it yet because the DNS records are still pointing to your old server. The only way someone else would reasonably hijack the process at this point is if they, too, had a custom name resolution set up with your server name and IP.
At this point, it’s all downhill. Open up the installer file’s name, whatever it is, and fill in the database credentials, and sit back and wait; Duplicator Pro replicates all of the old data and the entire filesystem of the WordPress installation from which you created the package.
It then asks you to log in as an administrator, and gives you an easy one-click process to delete the package’s files (which leaves you with a handy clean installation of your original WordPress installation).
At this point, all you have left to do – after clicking around in the new instance just to make sure things look right, and they should – is change the actual DNS records to point to the new host IP.
Don’t forget to change the A record (the IPv4 address) and the AAAA record (the IPv6 address).
After that, it’s a waiting game; normally DNS lookups are cached for an hour, so even if someone’s using your site actively, after an hour they’ll be using your new WordPress installation. They may have to log back in (if they’re logged in, of course) but that’d be the extent of the migration from their perspective (unless, of course, they added content while you were doing the migration; that content would be lost unless you do another backup and import.)
Really, a marvelously painless process.