WordPress multisite content migration: an agency guide

WordPress multisite is common in agency portfolios — a network for a franchise, a university department tree, or a holding company with a subsite per brand. When one subsite needs a full rebuild on ACF blocks, or the whole network splits into standalone installs, the migration rules you use on single sites still apply — but the plumbing around users, media URLs, domain mapping and shared themes adds steps that catch teams who've only migrated single sites before.

Know which migration type you're doing

Shared resources that trip people up

Media library

On standard multisite, media may live in a shared uploads folder (sites/site-id/…) or per-site depending on configuration. When you crawl a subsite for migration, image URLs include the site path. Your sideload step must resolve the correct absolute URL for that subsite, not the main network domain. After migrating to a standalone install, every image needs to exist in that install's own uploads — not reference the network path.

Users and authors

Network users can be members of multiple subsites. If you're moving one subsite to a standalone site, decide which authors come across and whether their user IDs will change. Post attribution breaks silently when author IDs don't map. Export a user list with email → new user ID mapping before bulk import.

Domain mapping

Mapped domains (subsite.client.com pointing at site ID 4) mean your crawl URL is the mapped domain, not network.client.com/subsite/. Crawl what Google indexes. Redirect maps must account for the domain change if the subsite is moving to its own domain entirely.

Rebuilding one subsite on ACF blocks (network stays)

1. 1Activate or develop the new block theme on that subsite only — network-enable it if other sites will share the library later.
2. 2Export ACF field groups from the subsite's active theme (or the shared theme if blocks are network-standardised).
3. 3Crawl the subsite's public URLs using its mapped or subdirectory URL.
4. 4Import drafts on that subsite's staging environment — subsite staging, not the main network site.
5. 5QA within the subsite context: menus, internal links stay within that site's URL space.
6. 6Launch on the subsite; network admin and other subsites are unaffected.

Extracting a subsite to a standalone install

This is the heavier path — the subsite leaves the network entirely. Tools like NS Cloner or manual export move tables and files, but content still needs re-mapping if you're rebuilding on ACF blocks at the same time. Typical sequence:

1. 1Stand up a fresh single-site WordPress install with the new ACF block theme.
2. 2Crawl the subsite on the network (while still live) and migrate content into the new install via bundle import.
3. 3Migrate users who need access; reassign post authors.
4. 4Sideload all media into the new install's uploads — don't rely on cross-install hotlinking.
5. 5Build redirect map from old subsite URLs to new standalone URLs — especially if the domain changes.
6. 6DNS cutover: point the domain at the new install; keep network subsite redirects live during transition.

SEO and governance on networks

• arrow_rightEach subsite may have its own Search Console property — submit sitemaps per property after migration.
• arrow_rightNetwork-wide robots.txt may not reflect per-subsite needs; verify after rebuild.
• arrow_rightShared SEO plugins sometimes store network defaults that override subsite settings — check per-site Yoast/Rank Math config.
• arrow_rightCookie consent and analytics may be network-managed; subsite rebuilds can break tracking if GTM containers reference old paths.

Single-site migration fundamentals — redirect maps, internal links, staging workflow — all still apply. Multisite is those same checks with site ID and domain awareness.

Network-wide block libraries

Agencies standardising on one ACF block library across a franchise network should network-activate the theme or mu-plugin registering blocks only after every subsite's content model is compatible. A block library built for subsite A's CPTs may break subsite B's editors. Version ACF JSON in Git; deploy to network in phases with per-subsite crawl-and-map runs.

Worked example: franchise subsite to standalone

A franchise location subsite on site ID 7 uses mapped domain location.client.com with forty UX Builder pages. Extract to standalone WordPress: crawl location.client.com, import ACF block drafts on new install, rsync sites/7/ uploads folder, remap forty authors to three local editors, 301 forty-two URLs from old paths, DNS cutover Friday night. Network subsite left with 301 to new domain for ninety days. Multisite overhead: two extra dev-days vs identical single-site migration.

Network plugins and subsite plugin tables

Multisite plugin activation states differ from single-site installs. Network-activated plugins run on every subsite; subsite-activated plugins store options in per-site tables (wp_2_options, wp_3_options, etc.). When you crawl subsite 4's content, SEO meta and ACF field groups may reference plugin settings stored in that subsite's options table — not the main network site. Export ACF JSON from the subsite where blocks are registered, not from network admin unless the block library is genuinely network-wide.

• arrow_rightConfirm which plugins are network-active vs subsite-active before migration.
• arrow_rightACF field groups: export from the subsite that will receive the import.
• arrow_rightSEO plugin global settings: copy per subsite — network defaults may override unexpectedly.
• arrow_rightCaching plugins on multisite may serve stale crawl output — bypass cache during crawl window.

NS Cloner versus crawl-and-map rebuild

NS Cloner and similar tools copy subsite tables wholesale — fast for lift-and-shift host moves, wrong for ACF block rebuilds. Cloning preserves Elementor meta, UX Builder shortcodes, and every builder artifact you are trying to escape. Use clone when the destination is identical structure on a new host; use crawl-and-map when the subsite rebuilds onto native ACF blocks. Many franchise projects combine both: clone to staging for reference, crawl production for clean import into the new theme.

Subsite table prefixes and database hygiene

WordPress multisite assigns table prefixes by site ID — wp_2_posts, wp_2_postmeta for site 2. Developers exporting meta manually must filter by blog_id. WP-CLI commands need --url=subsite.example.com to target the correct context. Running search-replace on the whole network without blog scoping corrupts unrelated subsites — a mistake that ends careers on large networks.

1. 1Use wp site list to confirm site IDs and URLs.
2. 2Run wp export --url=mapped-domain.test on the subsite being migrated.
3. 3Scope SQL queries with blog_id or correct table prefix.
4. 4Test search-replace with --dry-run on subsite tables only.
5. 5Back up the entire network before any bulk operation — not just the target subsite.

Franchise and multi-brand governance

Franchise networks share brand guidelines but differ in local content — phone numbers, addresses, team photos, service area copy. A shared ACF block library with localised repeater rows works well; a single crawl of the corporate site does not populate franchise location pages. Plan per-subsite crawls or a spreadsheet-driven local content merge after importing the corporate template bundle.

Multisite staging environments

Staging a single subsite on a multisite network is awkward — network themes, mu-plugins, and shared user tables complicate isolation. Options: clone subsite to a standalone staging install (cleanest for ACF rebuild QA), use a subdomain staging mapped to one site ID, or local development with exported subsite tables. QA internal links within the subsite scope — links pointing at other subsites on the network need explicit decisions when extracting to standalone.