You migrate a WordPress multisite network by treating each site in the network as its own migration, with its own content, its own URL map, and its own redirects, while deciding up front whether to keep them linked or split them into independent standalone sites. A multisite is several sites sharing one install, joined by shared users, plugins, and domain mapping, so the complexity is not the content of any one site but the shared layer and the number of sites. The reliable approach is to inventory every subsite, migrate each one faithfully with URLs preserved and 301s mapped per site, and reconstruct the shared pieces, users and domains, deliberately on the new setup. A migration is often the right moment to split a network into cleaner independent sites, since the reason to share one install rarely survives the move. WPBuildAI scopes each subsite, preserves its URLs with verified 301s, and rebuilds them as clean standalone sites or a coherent set, so the whole network moves without losing rankings.

Understand what a multisite actually is

The starting point is seeing where the complexity lives. A WordPress multisite is several distinct sites running on one shared installation, joined by a shared user table, shared plugins and themes, and domain mapping that lets each subsite answer on its own domain or subdomain. The content of any single subsite is ordinary, a set of pages and posts like any site. What makes a multisite migration different is the shared layer and the count: many sites to move, plus the connective tissue between them. So the mental model is not one big site to migrate but a portfolio of sites plus a shared foundation, and getting that model right is what keeps the migration organized rather than overwhelming.

Migrate each subsite as its own project

The reliable method is to decompose the network. Inventory every subsite, then treat each as its own migration: its content moves faithfully, its URLs are preserved, and its redirects are mapped per site, exactly as any single migration that keeps its SEO would. This matters because a network’s redirects are per-site, and the common failure is missing one subsite’s URL map entirely, silently losing that site’s rankings. So extract every URL across every subsite, as in mapping all URLs for redirects, and track each subsite’s migration to completion separately. Since traffic concentrates on a minority of pages, per the Ahrefs study, and often on a minority of the subsites, prioritize the sites and pages that actually earn traffic while still accounting for all of them.

Reconstruct the shared layer deliberately

The shared pieces are what a naive migration forgets. Shared users have to be reconstructed on the new setup, with the caveat that passwords are hashed and generally require resets, the same as any user account migration. Shared plugins become the new platform’s equivalent features, per site as needed. And domain mapping, the arrangement that let each subsite answer on its own domain, has to be reproduced so every subsite still resolves at its intended address. This shared layer is where multisite complexity concentrates, so handle it explicitly rather than assuming it comes along. Reconstructing users, features, and domain mapping deliberately is what turns a tangle of shared dependencies into a clean set of working sites.

Use the move to split, where it fits

A migration is often the moment to reconsider the network itself. Multisite exists mainly for central management convenience, and that reason rarely survives a move to a modern platform, where independent sites are simpler, more robust, and free of the shared single point of failure. So ask, for each subsite, whether it is better off as a standalone site on its own domain, which frequently it is, or whether a genuine set of related sites benefits from staying coherent. The subdomain-versus-subdirectory question often surfaces here too. Do not preserve the multisite structure out of habit; the move is your chance to simplify, and splitting into standalone sites is commonly the cleaner outcome, provided each keeps its URLs and redirects intact.

Phase a large network

Because a network is many sites, scale is a real factor, and you rarely have to do it all at once. A large multisite can be migrated in phases, moving subsites in batches rather than attempting the entire network in a single cutover, which is the same principle as migrating a large website in phases. Phasing reduces risk, lets you verify each batch before moving the next, and keeps the shared layer manageable as you go. Sequence by value, migrating the highest-traffic subsites carefully and early so their rankings are protected first, and confirming each phase settled, since a careful site move benefits from verification at each step. Phasing turns an intimidating all-at-once network migration into a series of ordinary single-site moves.

Steps to migrate a multisite network

  1. Inventory every subsite, its content, URLs, and mapped domain.
  2. Treat each subsite as its own migration with URLs preserved and 301s mapped.
  3. Reconstruct the shared layer: users (with resets), features, and domain mapping.
  4. Decide keep-or-split per subsite, favoring clean standalone sites where it fits.
  5. Phase large networks, migrating and verifying in batches by value.
  6. Confirm every subsite is complete and its redirects resolve before retiring the network.

Worked example: splitting a network into clean sites

Consider an agency running a multisite network of a dozen client-style sites on one install, sharing users and mapped domains, which had become fragile and hard to maintain. Migrating, they treated it as twelve migrations plus a shared layer: each site’s content and URLs were preserved and its redirects mapped, users were recreated with resets, and each site was rebuilt as an independent standalone site on its own domain rather than a mapped subsite. They phased it, moving and verifying a few sites at a time, starting with the highest-traffic ones. The network’s fragility disappeared, each site kept its rankings because its URLs were preserved, and management got simpler because the shared single install was gone.

Limitation: interdependent networks need careful planning

It is honest to bound this. Splitting works cleanly when subsites are effectively independent, but a network with genuine interdependencies, shared logins across sites, cross-site content, or a shared membership, is more entangled, and separating it takes real planning rather than a simple split, or a deliberate choice to keep certain sites linked. The shared user base in particular can be complex to reconstruct across many sites. So scope a multisite migration honestly: a loose network of independent sites splits easily, while a tightly integrated one is a substantial project that deserves detailed planning of the shared layer. Either way, the per-subsite URL and redirect discipline is what protects rankings, and the shared layer is what needs the most thought.

Key points

You migrate a WordPress multisite by treating each subsite as its own migration, with content moved faithfully, URLs preserved, and 301s mapped per site, while reconstructing the shared layer, users with password resets, features, and domain mapping, deliberately. The complexity is the shared layer and the number of sites, not any one site’s content, and the common failure is missing a subsite’s redirects, so inventory and track every subsite to completion. Use the move to split the network into cleaner standalone sites where that fits, since the reason to share one install rarely survives, and phase a large network in verified batches by value. Scope interdependent networks carefully, since shared logins or cross-site content take real planning to separate. WPBuildAI scopes each subsite, preserves its URLs with verified 301s, and rebuilds them as clean standalone sites or a coherent set, so the whole network moves without losing rankings. Send your web address for a free analysis.

Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.