A few weeks ago, I had a waking nightmare.
It started early one Tuesday afternoon and went well into the evening, and it was brought on by my casual agreement to help a client migrate one of three sites out of a WordPress Multisite installation to a standalone install. It started off so innocently…
(FYI, if you’re not familiar with Multisite, it’s a tool for setting up a network of WordPress sites all managed from the same admin dashboard. Learn all about Multisite.)
We originally set this Multisite installation up about 7-8 years ago as it seemed like the perfect solution to manage several sites from one dashboard. My client has disliked it ever since the newness wore off a few months after launch. And as her developer, I haven’t had a happy experience with it either. It seems really clunky and my client always found it difficult to use.
Breaking it up into separate sites seemed like too much bother, but this week she was finally ready, and based on the posts I saw about extracting sites from Multisite when researching the task, it didn’t seem like a big deal to me.
Nope. I was totally wrong about that. It was an enormously big deal.
I am no expert with Multisite by any means and this is not a complete guide to extracting a site from Multisite. But in hopes that I can help another developer get through this process without as much frustration (on the edge of tears a few times), I want to share some tips for this process that would have saved me a lot of time had I known them up front.
Tips for Multisite Extraction
1. When moving a site, normally I’d copy it with All In One WP Migration, which makes it super-easy to migrate a site from one host to another. But when using Multisite you can’t do that (there are some commercial plugins that will handle backups and sometimes migrations for Multisite installs, but they are much more complex than regular sites). So…
Start with a fresh install of WordPress, preferably on a test server you know well.
2. Copy the theme from the live site by downloading it via FTP and then uploading to the test site. Make sure it looks okay when you activate it.
3. Before attempting to move any content, you’re going to want to get all the plugins moved into your test site. You can manually install them one at a time, or you can copy the /wp-content/plugins/ folder from the live site to the test site.
4. For any plugins that need special settings, like WooCommerce, get those set up before migrating in the content from the live site. I didn’t do this the first time and wound up having to import content several times to get everything to come in correctly.
5. Once all plugins are set up and the theme is working fine, it’s time to get the content in. Using the WordPress Importer in Tools, export all the content from the live site. When you import into the test site, let it create the users it needs and be sure to check the tickbox to “Download and import file attachments.” See this guide for transferring content from one WordPress site to another.
6. Once the content is imported, check the entire site very carefully. If you find missing images, don’t panic.
This was one of the most frustrating parts of this entire process for me, as the images kept importing with missing data here or odd sizes there. And once they were finally all imported correctly, many were still showing broken links.
You’ll need to replace the URLs for the missing links in the database. I used phpMyAdmin for this.
Normally it’s super-simple to do a search and replace for these links, but what I didn’t notice at first is that Multisite puts a few extra directories in the URL. So what you’ll be doing is replacing something like this:
mysite.com/wp-content/uploads/sites/2/2019/05/my-image-name.png
with this:
sometestsitedomain.com/wp-content/2019/05/my-image-name.png
Note those extra folders in bold; you have to remove those in every link where they appear.
7. Once you have all the images looking good, check the site again, comparing it side-by-side to the live site. Even after multiple content imports we were still missing 3 widgets, two text widgets and a newsletter signup widget. While they were easy enough to recreate by referring to the live site (or a cached site like the Wayback Machine), we might have missed one or more without a comparison.
8. If everything now looks good, it’s very strongly advised to take a backup of the hosting account where the live Multisite is if like me you are replacing the Multisite with the new single install (you may or may not be doing this).
If you’re just moving the newly-created single install to another host, that’s easy (and as a developer you don’t need instructions for that). But if you’re replacing the Multisite, you need a backup. Just in case.
If the client’s host tells you that their built-in backup system ‘works fine with Multisite’ or ‘backs up the entire account including Multisite,’ I’d make sure I had an external backup too. Don’t count on what your host says.
Unfortunately there aren’t many backup solutions that work with Multisite (another reason to stay away from it), and the ones that do are almost all commercial plugins. But it’s important so it has to be done. Buy a plugin and make a backup – and if your host claims to support it, make one there, too. You can’t have too many backups.
9. The last step is migrating the test site to the client’s host server. That’s the easiest part. Breathe a sigh of relief.
Alternatives to Multisite
If I were to advise a client with multiple sites now how best to manage them, I’d recommend getting something like MainWP and avoiding Multisite completely. But if you already have a Multisite situation on your hands, hopefully these tips will make extraction less of a banging-head-on-desk ordeal.