A WordPress Multisite network — one installation running many sites under it — is the most technically demanding WordPress migration, because you are moving not one site but a whole network with shared core files, a shared database structure, per-site tables, and a mapping of domains or subdomains to network sites. The same two-component model still applies (files plus database), but the database is more complex and the configuration must preserve the network’s internal structure. Done methodically, it is entirely achievable.

This guide explains how to migrate a WordPress Multisite network: what makes Multisite different, the extra configuration in wp-config.php and .htaccess, moving the network’s files and database, handling the per-site tables and domain mapping, the more involved search-and-replace, and testing a whole network before going live. By the end you will understand the specific complications of a network migration and how to handle each one safely.

What makes Multisite different

A WordPress Multisite network is a single WordPress installation configured to run multiple websites — the network — that share the same core files and the same database, while each individual site within the network has its own set of database tables for its content. This is fundamentally different from a standalone site, and it is what makes the migration more complex.

The extra elements you must preserve are: the network configuration itself (special constants in wp-config.php that turn on and define Multisite), the per-site database tables (each network site has numbered tables like wp_2_posts, wp_3_posts, and so on), the network-wide tables that hold the site mapping and network settings, and the way domains or subdomains map to network sites. A migration must carry all of this across intact, or the network breaks.

So while a Multisite migration is still fundamentally ‘files plus database, copied and reconnected,’ both the database and the configuration are more elaborate than for a single site. The two-component model holds, but the database has a network structure and per-site tables to preserve, and the reconnection involves Multisite-specific configuration. Understanding these extra elements up front is what lets you migrate a network without dismantling it in the process.

The extra configuration to preserve

The reconnection step of a Multisite migration involves more than a standalone site, because Multisite relies on special configuration in two files. In wp-config.php, Multisite is enabled and defined by a set of constants — flags that turn on Multisite, declare whether it is subdomain- or subdirectory-based, and set the network’s domain and path. These must be carried over and updated for the new environment, or WordPress will not recognise the network.

The .htaccess file (or its equivalent on the server) also contains Multisite-specific rewrite rules that route requests to the correct network site. These rules differ between subdomain and subdirectory Multisite setups, and they must be present and correct on the new host, or the network’s URLs will not resolve properly.

So a Multisite migration’s reconnection is: update wp-config.php with the new database credentials as usual, but also ensure the Multisite constants are present and correct, and ensure the .htaccess (or server config) has the right Multisite rewrite rules for your setup. This is the extra configuration layer that a standalone migration does not have. Preserving and correctly adapting both files to the new host is essential — miss the Multisite constants or the rewrite rules, and the network will not function even though the data is all there.

Moving the files and database

Moving the network’s files works the same as any WordPress migration — you copy the entire installation (core, wp-content with all themes, plugins, and the uploads for every network site) from the old host to the new. Note that Multisite organises uploads per site (in subfolders under wp-content/uploads/sites/), so make sure the media for all network sites comes across, not just the main site’s.

The database is where Multisite differs most. You export the entire database as usual, but be aware it contains far more tables than a single site: the shared network tables, the main site’s tables, and a numbered set of tables for every additional network site. All of these must be exported and imported together, as they form the interconnected whole of the network — you cannot pick and choose. A complete database export and import is essential.

• All files: copy the whole installation, ensuring per-site uploads under sites/ come across for every network site.
• Complete database: export and import the entire database — network tables, main-site tables, and every numbered per-site table set together.
• New empty database: create one on the new host and import the full dump into it.
• Keep structure intact: do not rename or reorganise tables; the network relies on their exact names and relationships.

The key discipline is completeness: because a Multisite network is an interconnected whole, a partial file or database transfer breaks it. Move everything — every site’s files and every table — and preserve the exact structure. Once the complete files and the full database are on the new host, you reconnect with the Multisite-aware configuration described above, and the network is assembled. The extra care compared to a single site is simply that there is more to move and it is more interconnected.

The more involved search-and-replace

Search-and-replace on a Multisite migration is more involved than on a single site, because a network has multiple domains or subdomains stored across its many tables, and if any of them change, all must be updated correctly and consistently. Each network site may have its own URL, and these are recorded in the network tables (the site mapping) as well as within each site’s own tables.

If you are moving the network to a new domain, or changing the subdomain/subdirectory structure, you must update every affected URL throughout the database — the network’s main domain, each site’s mapped domain or path, and the URLs stored inside each site’s content — using a tool that handles WordPress’s serialised data safely and understands the network structure. A naive replace risks corrupting serialised data or leaving some network sites pointing at old locations.

So budget extra care for the search-and-replace on a Multisite move, especially if domains change. For a pure host migration keeping all the same domains, this may be minimal, but any URL change ripples across the whole network and every site within it. Using a Multisite-aware migration tool or a careful, network-conscious search-and-replace is what keeps every site in the network correctly addressed after the move. This is one of the steps where a network migration most rewards methodical attention.

Testing a whole network

Testing a migrated Multisite network is more work than testing a single site, because you must verify not just one site but the network as a whole and each site within it. Before going live, using a private preview, confirm that the network admin loads and functions, that the main site works, and then that each individual network site loads correctly with its own content, images, and settings intact.

Pay particular attention to the things Multisite can break: each site resolving to its correct domain or subdomain, per-site media loading (from the correct sites/ subfolder), the network admin’s site list showing all sites, and any per-site plugins or themes working. A network migration can succeed for the main site while a sub-site is broken, so checking every site — or at least a representative sample plus all important ones — is necessary.

So plan for network-wide testing: the network admin, the main site, and each network site, checking content, media, domains, and functionality across the whole network before you point anything live. This thoroughness is the natural consequence of migrating many sites at once. Once the whole network is verified working on the new host, you cut over as with any migration — update DNS (for the network domain and any mapped domains), keep the old host alive through propagation, re-verify the live network, and retire the old host last. A network migration is more work throughout simply because there is more of it — but each step is the familiar migration process, applied network-wide with the structure preserved.

FAQs

How do I migrate a WordPress Multisite network?

It’s a WordPress migration with the network structure preserved. Copy the entire installation’s files (including per-site uploads under sites/) and the complete database (network tables plus every numbered per-site table set), create a new database on the new host and import it all, then reconnect via wp-config.php keeping the Multisite constants, ensure .htaccess has the right Multisite rewrite rules, run a network-aware search-and-replace if domains change, and test every network site before going live.

What makes migrating Multisite harder than a single site?

Multisite is one installation running many sites that share core files and a database, with per-site numbered tables, network-wide tables holding the site mapping, special wp-config.php constants, and Multisite rewrite rules in .htaccess. The two-component model (files plus database) still applies, but the database is more complex and the configuration must preserve the network’s internal structure — miss any and the network breaks.

What configuration must I preserve for a Multisite migration?

The Multisite constants in wp-config.php (which enable and define the network, its subdomain/subdirectory type, domain, and path) and the Multisite rewrite rules in .htaccess (which route requests to the correct network site, differing between subdomain and subdirectory setups). Both must be present and correctly adapted to the new host, or WordPress won’t recognise or route the network even though the data is intact.

Do I need to move all the database tables for Multisite?

Yes — the whole database, together. A Multisite database holds shared network tables, the main site’s tables, and a numbered set of tables for every additional network site, all interconnected. You can’t pick and choose; a partial transfer breaks the network. Export and import the complete database, and don’t rename or reorganise tables, since the network relies on their exact names and relationships.

Why is search-and-replace harder on Multisite?

Because a network has multiple domains or subdomains stored across its many tables — the network’s main domain, each site’s mapped domain or path, and URLs inside each site’s content. If any change, all must be updated consistently using a tool that handles serialised data safely and understands the network structure. A naive replace risks corrupting data or leaving some network sites pointing at old locations.

How do I test a migrated Multisite network?

Test network-wide, not just one site: confirm the network admin loads and lists all sites, the main site works, and each individual network site loads with its own content, media (from the correct sites/ subfolder), domain/subdomain, and functionality intact. A network migration can succeed for the main site while a sub-site is broken, so check every site — or at least all important ones — before going live.

The bottom line

Migrating a WordPress Multisite network is the most technically demanding WordPress move, but it remains, at heart, the familiar ‘files plus database, copied and reconnected’ process — applied to a whole network and with its internal structure carefully preserved. What makes it harder is that a Multisite is one installation running many sites that share core files and a database, with a numbered set of tables for each network site, network-wide tables holding the site mapping, special Multisite constants in wp-config.php, and Multisite rewrite rules in .htaccess. Every one of these must come across intact: copy the entire installation’s files including each site’s uploads, export and import the complete database as an interconnected whole without renaming tables, and reconnect not just with the new database credentials but with the Multisite constants and rewrite rules correctly adapted to the new host.

Two steps demand extra care beyond a single-site move. The search-and-replace is more involved, because a network stores multiple domains or subdomains across many tables, and any URL change must ripple consistently through the network mapping and every site’s content, using a network-aware tool that handles serialised data safely. And testing must be network-wide: the network admin, the main site, and each individual network site, checking content, media, domains, and functionality, since a migration can succeed for the main site while a sub-site quietly breaks. Once the whole network is verified working on the new host, you cut over as with any migration — update DNS, keep the old host alive through propagation, re-verify, and retire the old host last. A network migration is more work throughout simply because there is more of it, but each step is the standard migration process applied methodically, network-wide, with the structure kept intact.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Migrating WordPress Multisite is a normal files-plus-database move applied network-wide with the structure preserved: copy all files (including per-site uploads), the complete database (network + every per-site table set), reconnect via wp-config.php keeping the Multisite constants, fix .htaccess rewrite rules, run a network-aware search-and-replace if domains change, and test every network site — not just the main one — before cutting over DNS and retiring the old host last.