WordPress multisite very rarely makes sense. It sells itself as tidiness: one install, one login, one set of plugins to update. That tidiness lasts until the sites start to differ, and sites with different owners, audiences or budgets start to differ quickly.
Every site in the network runs from the same WordPress files, the same plugins and the same theme code, with one database holding a set of tables per site, so anything you do to the shared parts, you do to every site at once.
One Update Window for Every Site
A wine-industry client came to us in August 2023 with two small multisite networks. Each site served a different part of his business: the main company site, a brokerage, an image library, a news site, a cellar group. He had not chosen to move. His previous host had decided it no longer wanted to run multisite, and a network is harder to rehome than a site. Many hosts will not take one at all, and several managed hosts only offer multisite on their higher plans.
We moved both networks across in under two weeks. By January 2024, edits to one subsite were no longer showing on the live site. We built that site again as a standalone install rather than keep chasing the network.
The bigger cost was updates. We run security updates on every site monthly, as described in Updates Should Be Scheduled and Deliberate. On a network, a plugin update lands on every site at the same moment. The sites shared plugins but not purposes, so an update tested against one site could still break another, and we could not update one without risking all of them. From July 2024 our advice was to separate them. This year we extracted the remaining sites, between June and September, mostly waiting on the client between steps. The extraction was included in his hosting.
Leaving Is Not a Normal Migration
Moving a standalone WordPress site is routine: copy the files, copy the database, change the domain. Moving a site out of a network is not, because the network has spread each site across shared structures:
- Its content lives in numbered tables. Site 7’s posts are in tables with a
_7_prefix, sitting in the same database as every other site. - Its media sits under
uploads/sites/N, not where a standalone site keeps it, and every image URL in the content points there. - Its users are shared with every other site. There is one user table for the whole network. Pulling one site out means deciding which users go with it. On the wine client’s extraction, the super-admin account was not copied at first, so logins failed until we added it.
- Its settings are serialised. WordPress stores many settings as serialised PHP, where each string carries its own length. A plain search-and-replace of the domain corrupts them.
Once It Is Automated, It Is a Procedure
On a schools platform we are moving roughly 90 school sites out of one shared multisite. Each school gets its own WordPress install, its own database, its own CDN distribution and its own server user.
These schools looked like the textbook case for multisite: same platform, same page builder, same kind of content. They are also 90 different owners, with their own staff, their own timelines and their own reasons to change something on their site and nobody else’s.
The extraction is one Ansible run per school. A recent run finished in about 13 minutes: 333 tasks, none failed. The problems we hit along the way were each solved once in the automation instead of by hand on every site:
- File ownership. Media copied from the network kept the old shared owner, so the new site’s own server user could not manage its uploads. The run now resets ownership after the copy.
- URLs inside the page builder’s data. The page builder stores layouts as JSON, with slashes escaped, so
https://www.school.nz/wp-contentappears ashttps:\/\/www.school.nz\/wp-content. An ordinary replace misses those. One school’s staff pages had 29 of them. - Domains inside serialised settings, replaced with a tool that rewrites the string lengths.
We still check every site afterwards. One school’s run reported no failures and produced an empty staff directory. The cause was not the migration: that school had never had a staff list to copy.
When Multisite Still Fits
The cases where I would still choose multisite are narrow:
- one owner
- one theme and one plugin stack, updated on one schedule
- no site that might ever be sold, handed to another agency or turned into a store
Departments of one organisation can fit that. So can a franchise that really is one site with different logos. A university’s department sites, all run by one central web team, are the usual example.
Everything else I would build as separate sites and automate the shared work across them: updates, backups, plugin inventories, the same theme deployed everywhere.
If You Are on a Multisite Now
Three questions tell you whether your network still fits:
- Do all the sites have the same owner? If one of them could be sold or handed over, the sale will need it pulled out of the network first: its tables, its media folder and its users.
- Have you held back an update on one site because of another?
- Do the sites still share a plugin stack, or does each now need different plugins?
If you are on a multisite and no longer sure it fits, I am happy to look at which of your sites actually belong together.
