Migrate a WordPress Multisite Network Without Breaking Sites

Migrating a single WordPress install is mostly file copy, database export, DNS cutover, done. Migrating a Multisite network has three more moving parts that don't show up until something's already broken: per-site upload folders, a URL that's baked into half a dozen tables per subsite, and domain mapping that silently points visitors back at the wrong server. Here's how to move a network to Getwebup without waking up to "subsites 404" the next morning.

Why Multisite Migrations Break More Often Than Single-Site Ones

On a normal WordPress site, the site URL lives in exactly one place: wp_options. Search-replace that, you're mostly done. On Multisite, every subsite has its own wp_2_options, wp_3_options, and so on — one full options table per blog ID — plus network-wide tables (wp_blogs, wp_site, wp_sitemeta) that track which domain or path belongs to which blog ID. Miss one and that subsite either loads the wrong content or throws a database error while every other site on the network works fine.

Add domain mapping (custom domains pointed at subsites via a plugin like WP Domain Mapping or Mercator, or a sunrise.php drop-in) and you've got a fourth layer: a mapping table that has to agree with DNS, or visitors get bounced to the network's primary domain instead of their own.

Before You Touch Anything: What to Confirm First

• Is this a subdomain network (site1.example.com) or a subdirectory network (example.com/site1)? The install type is fixed in wp-config.php and can't just be re-decided on the new server.
• Run wp site list --fields=blog_id,domain,path via WP-CLI (or check Network Admin > Sites) and save that list somewhere outside the server. You'll need it to verify every subsite came across.
• Check whether any subsite uses a mapped custom domain. Look in Network Admin > Sites > Edit for each site, and check wp-content/sunrise.php or an active domain-mapping plugin.
• Take a full backup — files and database — and download it off-server before you start. If you're not sure how, our cPanel backup and restore guide covers the full account backup.

Step-by-Step: Moving the Network

Step 1: Export the Whole Database, Not Just the Main Site's Tables

A Multisite database export has to include every wp_{blog_id}_* table set plus the three network tables. Doing this from cPanel's phpMyAdmin, select the entire database, not a filtered list of tables — it's easy to accidentally leave out a subsite's tables if you're exporting by hand. From SSH, a full dump is simpler:

mysqldump -u dbuser -p --single-transaction dbname > multisite_full.sql

Copy the whole wp-content directory too, not just wp-content/uploads. Multisite stores each subsite's media under wp-content/uploads/sites/{blog_id}/ (subdomain installs) or a similar per-site path, and it's a common miss to grab only the main site's uploads folder.

Step 2: Import and Point wp-config.php at the New Server

Import the SQL dump into a fresh database on the new server, update the database credentials in wp-config.php, and confirm the Multisite constants match what the network actually is:

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true); // false for subdirectory networks
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

If DOMAIN_CURRENT_SITE doesn't exactly match the domain visitors will use post-migration, the network admin dashboard itself becomes unreachable, even before you get to subsites.

Step 3: Search-Replace Across Every Subsite Table, Not Just the Main One

This is the step people skip and then wonder why only site1.example.com got fixed. Use WP-CLI's network-aware search-replace so it walks every blog's tables in one pass:

wp search-replace 'https://old-server.com' 'https://example.com' --all-tables --network

--all-tables catches the network tables (wp_blogs, wp_site) alongside the per-subsite ones; --network tells WP-CLI to loop over every site ID instead of just the current blog. Without a shell, a plugin like Better Search Replace does support Multisite, but check its "network" scope option is ticked — by default some run against the current site only.

Step 4: Fix Domain Mapping Before You Touch DNS

If any subsite uses a mapped custom domain, the mapping record and DNS have to change together. For plugin-based mapping, open each mapped site in Network Admin and confirm the mapped domain still matches what's in wp_domain_mapping (the table name varies slightly by plugin/version). For a sunrise.php setup, that file has to be copied into wp-content/ on the new server and define('SUNRISE', 'on'); added back to wp-config.php — it's a drop-in, so a plain files-only migration silently loses it if you forgot it wasn't inside wp-content/plugins.

Step 5: Regenerate .htaccess and Confirm Wildcard DNS

Multisite's rewrite rules in .htaccess are network-aware and different from a single-site install. After the move, go to Network Admin > Sites and re-save permalinks, or copy the multisite-specific block that starts with RewriteRule ^wp-admin$ wp-admin/ from a working backup. For subdomain networks, confirm the new server has a wildcard A record (*.example.com) pointing at it, and that SSL covers the wildcard — a single-domain certificate will throw mismatch errors on every subsite the moment you cut over.

Step 6: Cut Over DNS Last, One Domain at a Time If You Can

Lower TTLs on the primary domain (and any mapped domains) a day ahead, then repoint them once you've confirmed subsites load correctly by editing your local hosts file against the new server's IP. If you're moving mapped custom domains too, stagger them rather than flipping everything at once — it makes it obvious which specific domain broke if something did.

Errors That Show Up Right After the Move

Preventing This Next Time

• Keep a standing export of wp site list --fields=blog_id,domain,path so you always have a source of truth to check against after any move.
• Store sunrise.php and any domain-mapping config outside the assumption that "copying wp-content copies everything" — note it explicitly in your migration checklist.
• Test the migration against a staging subdomain first, with hosts-file overrides, before touching production DNS. Our WordPress staging guide covers setting that up in cPanel.
• Document which subsites use mapped domains versus subdomains of the main network — six months later it's easy to forget which three sites need special handling.