Migrating From Single Sites to Multisite

Disclosure: To ensure total transparency regarding our independence, please note that this guide on migrating from single sites to multisite contains affiliate links we may

Consolidating a portfolio of separate WordPress installs into one multisite network is one of the few migrations that’s genuinely one-directional in practice — WordPress has no built-in “convert back” path, so this is worth getting right the first time rather than fast.

When this move actually pays off

Multisite makes sense when you’re maintaining 10+ near-identical client sites (same theme family, overlapping plugin stack) and you’re spending real hours every week on repetitive core/plugin updates across separate installs. It does not make sense if your clients run genuinely different tech stacks (some WooCommerce, some LMS, some brochure sites) — multisite shares one WordPress core and plugin files across the network, so wildly divergent needs fight each other. If fewer than half your sites share a common plugin baseline, stay on separate installs and manage them with MainWP or ManageWP instead.

Pre-migration audit — do not skip this

Before touching anything, build a spreadsheet of every site: active theme, active plugins with versions, PHP version, custom post types, and any hard-coded absolute URLs in content (common in older sites edited with classic-editor image embeds). Plugins that don’t declare multisite compatibility are the single biggest source of post-migration breakage — check each plugin’s page for a “Works with Multisite” note, and test unfamiliar ones on a staging network first. WooCommerce, Gravity Forms, and Rank Math all support multisite cleanly; smaller niche plugins are the actual risk.

The three practical migration paths

[AFFILIATE CTA: WP Migrate DB Pro]

WP Migrate DB Pro is worth the license cost specifically because its search-replace handles PHP-serialized data correctly (widget settings, some plugin options) — a plain find-and-replace in a database export will corrupt any serialized string whose length changes, which is exactly what happens when you’re changing domains and paths during a multisite import.

The actual step sequence

1) Spin up a brand-new WordPress install specifically for the network — do not try to convert one of your existing client sites into the network’s root, since the root site behaves differently (it can’t be deleted, and some plugins misbehave when network-activated from a site that used to be a normal single site). 2) Decide subdomain vs. subfolder before running the Network Setup Wizard in Tools > Network Setup — this cannot be changed after. 3) Add the generated code to wp-config.php and .htaccess. 4) For each client site being migrated in, create a new site in Network Admin, then import that client’s content via WordPress’s built-in importer or your migration tool of choice. 5) Media requires special attention — files that were at wp-content/uploads/2025/03/ on the standalone site need to land at wp-content/uploads/sites/{id}/2025/03/ in the network, and any hard-coded URLs in post content need updating to match, which is the step WP Migrate DB Pro’s serialized-safe replace is built for. 6) Re-activate each site’s plugins individually — multisite does not carry over which plugins were active on the standalone install.

The gotchas that actually cause outages

Theme functions.php files that call is_multisite()-unaware code, or that hard-code the site URL, break silently. Plugin license keys tied to a single domain (common with premium themes and page builders) need re-activating per sub-site, and some licensing systems count each network site as a separate activation, quietly eating into your license seat count. Users are also a common surprise: multisite has one shared user table, so if two client sites both happen to have a user with the same email, the import will conflict — resolve this in your pre-migration audit, not mid-import.

Realistic timeline

For an 8-10 site portfolio with a clean plugin baseline, budget 2-3 full days: one for setup and testing on staging, one to two for the actual per-site migration and QA, plus a buffer day for DNS/cache propagation issues on the sites that get domain-mapped. Rushing this into a single evening is the most common way agencies end up with a client site down during business hours.

Testing before you announce anything to clients

Once each site is imported, don’t skip a manual pass through the actual front end: submit a real test lead through every contact form, place a test order if WooCommerce is involved (then refund/delete it), check that scheduled cron jobs (backups, cache-warming) are still firing per-site rather than only on the network root, and confirm SSL certificates cover each mapped domain — a wildcard cert that covered subdomains on the old hosting setup won’t automatically cover custom mapped domains on the new network. Only after this pass should client-facing communication go out; a client discovering their own contact form is broken is a far worse first impression than a short, planned maintenance window.

What to tell clients, and what not to

Clients generally don’t need (or want) the technical detail of “multisite” — what they need is a heads-up about a maintenance window and confirmation nothing changes for their visitors. Keep the client-facing message to timing and expected downtime, and save the architecture explanation for your own internal documentation and the next teammate who has to maintain the network.

FAQ

Can I migrate just some sites to multisite and leave others standalone?
Yes — multisite doesn’t require an all-or-nothing move. Many agencies migrate only the sites sharing a common theme/plugin baseline and leave outliers on standalone installs.

Does multisite migration affect each client’s individual SEO?
Not if domain mapping and 301s (where URLs changed) are handled correctly during the move — rankings are tied to the final URL structure, not the underlying network architecture.

What’s the fallback if a migration goes wrong mid-way?
Always take a full database and file backup of both the source site and the fresh network install before starting — restoring the standalone site from backup is the actual rollback plan, since there’s no built-in “undo” for a partial network import.

Related reading: Multisite Plugin Management · When Multisite Is the Wrong Choice · Multisite Setup for Subdomains vs Subfolders