A multisite migration is not one migration — it is one per site, plus a network layer. Teams that treat it like a single-site move discover the gaps one subdomain at a time. Here is the structure of a clean network move.
What multisite changes structurally
- One database, many sites: network tables (
wp_blogs,wp_sitemeta) plus per-site tables with prefixes (wp_2_posts,wp_3_options…). Backups and search-replaces must handle the family, not just the base. - Uploads per site:
wp-content/uploads/sites/{id}/— file transfers must include the sites directory tree. - Two admin levels: network admin (super admin) and per-site admins — user roles and capabilities differ per site.
The migration order
- Inventory the network: list every site (ID, domain/path, active plugins, theme) with
wp site list --allow-root. This is your test plan. - Move files and the full database — all prefixed tables included; verify table count matches before and after.
- Search-replace domain — per site:
wp search-replace "https://old.com" "https://new.com" --all-tables --allow-rootcovers it if the domain is uniform; subdomain networks (site1.old.com) need each subdomain replaced individually. - Rebuild the network mapping: subdomain networks need DNS/wildcard SSL for every subdomain; subdirectory networks just work under the new domain. This is the step that surprises — wildcard certificates don’t transfer with anything else.
- Verify per site, in order: front end, admin login, media library (uploads paths differ per site), and menus/widgets per site. Network-level “it works” means nothing; site 7 may be fine while site 3’s uploads 404.
Multisite-specific traps
- Plugin licensing per site: many premium plugins license per domain — a network activation on the new domain may count as N new installations. Check license dashboards before the move.
- Sunrise/domain-mapping plugins: legacy mapped domains need their mapping tables updated — these break silently and serve wrong sites.
- Cache keys: shared object cache instances need a per-site key salt to avoid cross-site cache collisions.
- Stale cross-site links inside content — the search-replace catches domain swaps, but hand-written relative links between sites deserve a spot check.
Verification, the network way
Script the checks: for each site in wp site list, curl the front end (200), the admin (login redirect), and one attachment URL. One command over the inventory beats twelve manual visits — and catches the long tail. The migration service runs network moves with this scripted verification.
Network tables, per-site prefixed tables, per-site uploads directories, and per-site verification. A single-site approach misses subdomains, mapping tables, and the long tail of sites. Uniform domain: one wp search-replace over all tables. Subdomain networks: replace each subdomain individually — wp site list provides the inventory. Per-site uploads live in wp-content/uploads/sites/{id}/ — the sites directory tree must transfer completely, and file permissions must survive. Test one attachment per site. Often not — many premium plugins license per domain, and a network on the new domain reads as fresh installations. Review each license dashboard before migrating.How is multisite migration different from a normal WordPress move?
How do I search-replace domains in multisite?
Why do uploads 404 after a multisite migration?
Do plugin licenses transfer in a multisite move?
