A week ago I migrated my membership site Graceful.Dev from Nexcess to Cloudways. It was a pretty low-drama process, and I thought I’d write down what made it so while the memory is fresh.
First, a little bit of background for my developer nerds: moving a WordPress site isn’t quite like moving a Rails or Django or Java Spring site. A professional wordpress site consists of:
- WordPress itself, an off-the-shelf open-source application
- A wp-config.php file, which usually contains hosting-specific customizations.
- A collection of off-the-shelf plugins in a plugins directory, including licensed premium plugins
- A site-specific plugin for custom-coded modifications to WordPress or plugin behavior.
- At least one off-the-shelf theme, in a subdirectory
- A site-specific child-theme which adds local tweaks to the base theme
- A database full of content as well as configuration
- A directory full of uploaded images and other media, for attachment to blog posts etc.
Of these, only #4 and #6 are amenable to being version-controlled. Trying to keep the whole shebang in a VC repo is a recipe for pain and for falling behind on security patches.
Broadly speaking, moving an active multi-user WordPress site from one host to another goes like this:
- Do an initial migration of WordPress-and-plugins-and-themes-and-database to the new host, exposed on some temporary domain.
- Mess around with the new copy for a while. Remove caching plugins that were only relevant to the old host, enable any plugins that are specific to the new host (a lot of WordPress-centric hosts have their own recommended configuration for caching, backups, etc.). Ensure everything works as expected on the new host. This process might take a couple days.
- Add the new host to your continuous delivery automations for pushing out your site-specific plugin and child theme.
- [somehow] pull any database changes that happened in the meantime–updates to user accounts, comments, course progress, etc.–onto the new site without overwriting any of your host-specific tweaks.
- Do the same thing for any media that was added since the copy was made.
- Re-point the DNS from the old host to the new host
- Update the new site to think it lives at the canonical domain.
There are lots of tools to help you copy a WordPress site whole-hog from one site to another. Every host offers some variation on a one-shot migration. It’s #4 and #5 that are the tricky bits: copying over the things that have changed since you started the migration process, before retiring the old site.
For me, this was where WP Migrate DB Pro came in. This plugin (when used with its pro addons) can push or pull not just database records, but media files, plugins, and themes from one WordPress site to another. I’d been using it for months to pull the latest version of production into my staging site, for testing and experimentation.
Since WP Migrate DB was already in place in my workflow, the process of migrating to a new host was, essentially:
- Provision a vanilla WordPress installation
- Install WP Migrate DB Pro and add pull credentials for the original site
- Migrate everything with WP Migrate DB
- Tweak, test, yadda yadda
- Continue to pull database and media updates as-needed with WP Migrate DB
- Switchover once everything is ready and working
(As a bonus, WP Migrate DB Pro also includes a handy DB find-and-replace for updating hardcoded URLs once the switchover is complete.)
A shout-out as well to my DNS host DNSimple, which makes updating DNS records painless and fast.