WordPress Multisite Migration: Moving, Splitting and Merging Networks

A WordPress multisite migration is harder than a single-site move because one database holds many sites, and each site stores its own address in several places. To move a network safely, you copy the files and database, update the network tables and wp-config.php, run a network-wide search-replace, and check every site one by one. Splitting a site out of a network or merging sites into one takes more steps, but follows the same logic.

This guide explains how a network is stored, then walks through the three kinds of multisite moves we handle most often.

How multisite stores its data

Knowing the structure makes every migration step make sense. In a multisite network:

• Each site has its own tables. The main site uses the normal prefix, like wp_posts. Other sites get a number, like wp_2_posts and wp_2_options.
• Users are shared. All sites use the same wp_users and wp_usermeta tables. A user’s role on each site is stored in wp_usermeta.
• Network tables tie it together. wp_site holds the network’s domain and path. wp_blogs lists every site with its domain and path. wp_sitemeta holds network-wide settings.
• Uploads are split by site. Files for site 2 live in wp-content/uploads/sites/2/.
• wp-config.php defines the network. Constants like MULTISITE, SUBDOMAIN_INSTALL, DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE tell WordPress which network to load.

The WordPress multisite documentation explains the setup in more depth. The key point for migrations: a site’s address is stored in its own options table, in wp_blogs, sometimes in wp_site, and in thousands of links inside content. All of them must agree.

Moving a whole network to a new host or domain

1. Audit the network first

List every site, its domain and its status. With WP-CLI, the command-line tool for WordPress, this is one command:

wp site list --fields=blog_id,url,archived,deleted

Note any sites with mapped custom domains, any archived or deleted sites that can be removed, and plugins that are network-activated versus activated per site. A network that has grown for years often carries dead sites and unused plugins. Removing them before the move makes everything faster. Our technical debt audit checklist covers what to look for.

2. Copy files and database

Copy the full wp-content folder, including uploads/sites/. Export the whole database with wp db export or mysqldump, and import it on the new server. Check that the new server runs a supported PHP version and has URL rewriting enabled, since multisite requires it.

3. Update wp-config.php

If the main domain or folder changed, update these constants on the new server:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'new-example.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

If you see “Error establishing a database connection” on a network that worked before, a mismatch here is a likely cause. WordPress looks up DOMAIN_CURRENT_SITE in wp_site and wp_blogs and fails if it cannot find a match.

4. Run a network-wide search-replace

WP-CLI’s search-replace command handles serialized data, which a plain SQL replace would corrupt. The --network flag runs it across every table registered to the network. Always do a dry run first:

wp search-replace 'old-example.com' 'new-example.com' --network --skip-columns=guid --dry-run
wp search-replace 'old-example.com' 'new-example.com' --network --skip-columns=guid

We skip the guid column because the WordPress guide to moving sites says GUIDs should never change. If plugins created their own tables without the WordPress prefix, add --all-tables instead. See the search-replace reference for every option.

Searching for the bare domain, not the full https:// address, also catches protocol-relative links and subdomains. But be careful with subdomain networks: replacing old-example.com also changes shop.old-example.com, which is usually what you want, but check the dry-run output.

5. Check the network tables by hand

The WordPress documentation says to manually review wp_site and wp_blogs after a move, even if search-replace ran cleanly. Confirm that each row has the right domain and path:

wp db query "SELECT blog_id, domain, path FROM wp_blogs;"
wp db query "SELECT id, domain, path FROM wp_site;"

Then load the dashboard of each site, not just the main one. A site with a wrong siteurl or home option will redirect to the old domain or show a blank page.

6. Handle mapped domains

Sites with their own domains need DNS pointed to the new server and an SSL certificate for each domain. Plan certificates in advance. A network with dozens of mapped domains can hit rate limits if you request them all at once on launch day. For the DNS side of the switch, follow our guide to changing WordPress hosts with zero downtime.

Splitting one site out of a network

This is common when a business sells a brand, a department wants its own site, or one site has needs the rest of the network does not share.

1. Export the site’s tables

Find the site’s ID with wp site list. Export only its tables, for example everything starting with wp_5_. Then rename them to a single-site prefix, so wp_5_posts becomes wp_posts. You can do this in the exported SQL file or after import.

2. Bring the users along

Users are shared, so they are not in the site’s tables. Export the users who have a role on that site. With WP-CLI you can list them using wp user list --url=site5.example.com. On the new install, create these users and fix the role keys in wp_usermeta, which change from wp_5_capabilities to wp_capabilities (and wp_5_user_level to wp_user_level). Also check that post authors still match the right user IDs, since IDs can differ on the new install.

3. Move the uploads

Copy wp-content/uploads/sites/5/ into wp-content/uploads/ on the new site. Then run a search-replace for the path, from /uploads/sites/5/ to /uploads/, along with the domain change if there is one.

4. Rebuild plugins and settings

Network-activated plugins were active on every site, but their settings may live in wp_sitemeta, which you did not export. Install the plugins on the new site and confirm each one’s settings. This is where splits most often go wrong: a form plugin, a license key or an SEO setting quietly disappears.

5. Redirect if the address changes

If the split site moves from a subfolder (example.com/brand/) to its own domain, add 301 redirects from every old URL to the new one. Our WordPress migration SEO checklist covers redirects, Search Console and monitoring step by step.

Merging sites into a network

Merging separate WordPress sites into a multisite network is the reverse of a split, and usually the most work.

Small sites: use the WordPress importer

For sites with mostly posts, pages and media, create a new site in the network and use the WordPress export and import tools, which use WXR files. This handles content, categories, tags and authors. It does not move plugin settings, widgets, menu locations or custom tables, so you rebuild those by hand.

Large or complex sites: move the tables

For sites with stores, memberships or form entries, we move the database tables directly and rename them to the new site’s prefix (for example, wp_ to wp_7_). The hard part is users. Each source site has its own user table, with IDs that can collide with existing network users. You need to merge users by email address, update every reference to old user IDs (post authors, order customers, form entries), and rename capability keys in wp_usermeta. This needs a script and a test run, not a manual process.

Before you merge, ask if you should

Multisite makes sense when sites truly share code and users. If the sites need different plugins, different update timing or different owners, one network can make each update riskier, because one bad plugin can affect every site. We often recommend keeping sites separate and managing them with shared tooling instead.

Testing a multisite migration

With many sites, manual clicking does not scale. We test network migrations with scripts that load the homepage and a few key pages of every site, check status codes, and look for the old domain in the HTML. We run the same checks before and after the move and compare. For more on this approach, see our guide to automated WordPress testing with Playwright and PHPUnit.

Planning a multisite move?

Multisite migrations reward careful planning and punish shortcuts. We have moved, split and merged networks with many sites and mapped domains, and we test every site before and after launch. If you have a network to move, see our WordPress migration service or contact us to talk it through.

Frequently asked questions

Can I move a WordPress multisite with a migration plugin?

Some migration plugins support multisite, often only in paid versions. They work for simple networks, but large networks or networks with mapped domains usually need a manual move with WP-CLI and direct database checks.

How do I move one site out of a multisite network?

Export that site's tables and its users, rename the tables to a standard single-site prefix, copy its uploads folder, and run a search-replace for its URLs. Then add 301 redirects if the address changes.

Do I need to change wp-config.php when moving a multisite?

Yes, if the domain or folder changes. The DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE constants must match the new main site address, and SUBDOMAIN_INSTALL must match the network type.

Should I convert my multisite into separate sites?

It depends on how much the sites share. If they use different plugins, have different owners or need different update schedules, separate installs are often easier to maintain. If they share a theme and users, a network can still make sense.