How to Migrate a WordPress Site to a Multisite Network: The 2026 Enterprise Guide

Managing 50 separate WordPress installations is an operational nightmare that destroys agency profit margins through duplicated maintenance overhead. Moving live websites with established SEO equity into a Multisite ecosystem carries critical risks. These risks include database corruption, stripped serialized data, and infinite redirect loops. This guide provides an enterprise-grade technical blueprint for a secure, structured, and SEO-friendly migration.

Pre-Migration Checklist: Preparing Your Enterprise Infrastructure

Preparing your enterprise infrastructure for a Multisite migration requires strict server resource allocation, comprehensive database backups, and a finalized network architecture decision before modifying any core files.

Full Server Backups and PHP Resource Allocation

Allocating sufficient PHP resources prevents server timeouts during massive database table imports and URL rewriting processes. You must configure your wp-config.php and php.ini settings before initiating data transfers.

Set WP_MEMORY_LIMIT to a minimum of 512M for standard sites and 1024M for complex WooCommerce migrations. Increase max_execution_time to 600 seconds. Failure to adjust these limits will result in fatal errors and incomplete database imports.

You need direct access to your database schema. Use raw database management tools like TablePlus or phpMyAdmin to export a complete, uncompressed .sql backup of the source site. Relying on basic backup plugins for enterprise environments introduces unnecessary risk. You require a raw database dump to ensure absolute data integrity and fast rollback capabilities.

Evaluating the Subdomain vs. Subdirectory Architecture

A subdomain architecture uses distinct DNS records for each network subsite, while a subdirectory architecture routes traffic through virtual folders mapped on the primary domain.

You must finalize this architectural decision immediately. Subdirectories ([domain.com/siteA](https://domain.com/siteA)) share the primary domain authority but can create permalink conflicts with existing top-level pages. Subdomains (siteA.domain.com) require wildcard SSL certificates and careful DNS propagation but offer superior structural isolation for B2B client portals. I have written about this more extensively in the article WordPress Multisite vs. Multiple Installations: The Enterprise Architecture Guide.

Below is an interactive architecture visualizer to clarify the routing differences before you begin server configuration.

Phase 1: Activating the Multisite Network on the Destination Server

Activating a Multisite network on the destination server requires modifying core configuration files before importing any external database tables. You are establishing the global architecture that will govern how the primary domain and all future subsites interact with the server routing.

Modifying wp-config.php and .htaccess

You must inject specific PHP constants into your wp-config.php file to enable the network administration dashboard and define your routing architecture. Open your wp-config.php file above the /* That's all, stop editing! Happy publishing. */ line and add the activation constant.

define( 'WP_ALLOW_MULTISITE', true );

Once saved, refresh your WordPress dashboard and navigate to Tools > Network Setup. This interface will generate the exact constants and rewrite rules required for your chosen architecture (Subdomain or Subdirectory). For absolute technical precision regarding the setup interface, refer to the WordPress.org Official Docs{:target=”_blank” rel=”noopener”}.

After the network setup generates the rules, return to your wp-config.php and define the network environment. A standard subdomain configuration looks like this:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'agency-network.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Next, replace the existing WordPress routing rules in your .htaccess file (for Apache servers) or nginx.conf (for Nginx servers) with the Multisite-specific rewrite rules provided in the dashboard. This ensures the server correctly intercepts and routes traffic based on the requested subsite.

Creating the Empty Destination Subsite

Creating an empty subsite generates the unique Site ID required to route the incoming database tables accurately. The Multisite architecture relies on an incremental ID system to separate data environments.

Navigate to Network Admin > Sites > Add New. Input the subsite address, title, and an administrative email. When you create this site, WordPress automatically generates a new set of database tables specifically for this instance. If this is your first subsite, it will be assigned Site ID 2.

WordPress creates tables with a specific prefix pattern: wp_2_posts, wp_2_options, wp_2_postmeta, and so on. These empty tables serve as the exact structural blueprint you will overwrite during the database merging phase.

Phase 2: The Migration Process (Single Site to Network Subsite)

The migration process involves extracting data from the single site and injecting it into the newly created Multisite subsite repository while preserving relational integrity. The method you choose dictates the security of your serialized data and the structural integrity of your network.

Method 1: WP-CLI and Native Export/Import (For Content-Only Sites)

Utilizing native XML exports is only viable for lightweight architectures lacking complex custom post types or heavy meta queries. If the source site consists primarily of standard posts and pages, you can bypass direct database manipulation.

Access your server via SSH and utilize WP-CLI to export the content. This bypasses PHP timeout limits associated with browser-based exports.

wp export --dir=/tmp/ --user=admin

Move the generated XML file to the destination server and run the import command directed at the specific subsite URL. While safe, this method is highly inefficient for enterprise data sets.

Method 2: Direct Database Table Merging (For Complex & WooCommerce Sites)

Consolidating high-traffic WooCommerce stores or complex directory sites requires direct database table merging. You must isolate the source database tables, rename their prefixes to match the destination Site ID, and inject them into the Multisite database.

Using industry-standard tools like WP Migrate or TablePlus allows you to inspect and manipulate SQL queries directly. You are effectively replacing the empty tables generated in Phase 1 with the rich data from your standalone site.

The most critical step is renaming the database prefixes precisely. Below is the strict mapping protocol comparing standard single-site tables against a Multisite ID 2 structure.

To help visualize and plan the table renaming process before executing raw SQL commands, use the interactive Table Prefix Conversion Calculator below.

Managing the Media Library and Upload Paths

Multisite architecture fundamentally alters the physical storage path of media assets by shifting from a global directory to site-specific virtual directories. When you migrate a single site database into a network subsite, all existing media URLs remain hardcoded to the old file structure. You must physically synchronize the files and execute precise database URL replacements to restore asset visibility.

Synchronizing Physical Files

In a standard standalone WordPress installation, uploaded media resides in the wp-content/uploads/ directory. In a Multisite network, media for secondary sites is routed to a numbered directory corresponding to the specific Site ID, such as wp-content/uploads/sites/2/.

You must connect to your destination server via SFTP or SSH. Navigate to the wp-content/uploads/sites/ directory and create a new folder named after your target Site ID. Transfer the contents of the uploads folder from your single site backup directly into this new sites/2/ folder. Do not overwrite the primary network’s uploads directory, as this will cause catastrophic conflicts with the main site’s existing media library.

Database URL Replacement without Serialized Data Corruption

Updating image URLs requires executing precise database search and replace operations to prevent corrupting serialized data arrays used by advanced themes and page builders. A standard SQL UPDATE query will strip serialized PHP strings and break complex page layouts entirely.

You must utilize tools designed to handle PHP serialization safely. For GUI-based operations, plugins like Better Search Replace Pro provide a secure interface. However, for enterprise-scale migrations involving gigabytes of data, you must execute terminal commands. Use the WP-CLI search-replace documentation{:target=”_blank” rel=”noopener”} as your reference to execute the following command structure via SSH:

wp search-replace 'old-domain.com/wp-content/uploads' 'agency-network.com/wp-content/uploads/sites/2' --network --dry-run

Always run a --dry-run first to validate the exact number of tables and strings that will be modified before committing the changes to your production database.

Domain Mapping: Pointing Your Old Domain to the New Subsite

Domain mapping allows a network subsite to operate under a custom top-level domain instead of a native subdomain or subdirectory structure. This ensures your B2B clients maintain their brand identity and canonical URLs while residing within your centralized server infrastructure.

DNS Configuration (A Records and CNAMEs)

You must configure your domain registrar’s DNS settings to route traffic directly to the primary IP address of the Multisite network server. The server must be capable of receiving traffic for unassigned domains.

Log into your DNS provider and update the primary A Record (for the root domain @) to point to the Multisite server’s IP address. Create a CNAME Record for the www alias pointing to the root domain. If you utilize a content delivery network or enterprise proxy, refer to the Cloudflare DNS management guide{:target=”_blank” rel=”noopener”} to ensure proxy caching does not interfere with the domain handshake.

Below is an interactive DNS mapping validator to visualize the required routing logic before propagating your changes globally.

Native Domain Mapping (No Plugins Required)

WordPress core supports native domain mapping without third-party plugins. You manage this configuration directly through the Network Admin interface once the DNS propagation is complete.

Navigate to Network Admin > Sites > All Sites. Hover over your newly populated subsite (Site ID 2) and click Edit. Locate the Site Address (URL) field. By default, this field displays the internal network routing address (e.g., [https://client.agency-network.com](https://client.agency-network.com)). Erase this internal URL and replace it with the exact, custom top-level domain ([https://client-domain.com](https://client-domain.com)).

Save the changes. Ensure your server environment is configured with Server Name Indication (SNI) and that a wildcard SSL or a specific Let’s Encrypt certificate is issued for the new mapped domain. Failing to secure the alias domain will result in strict browser security warnings.

server {
    server_name client-domain.com;
    return 301 $scheme://agency-network.com/client$request_uri;
}

When to Outsource Your Multisite Migration

Outsourcing your migration is a calculated risk management strategy when dealing with high volumes of serialized data, complex server routing, or mission-critical B2B portals. Standard automated migration plugins fail completely when evaluating network-activated vs. site-activated plugin dependencies.

If your single site relies heavily on object caching (Redis/Memcached), custom database tables generated by LMS platforms, or complex WooCommerce taxonomy relationships, merging the database requires surgical precision. A failed regex search-and-replace will permanently corrupt serialized data arrays, rendering page builder configurations and widget settings unrecoverable.

Consolidating highly customized enterprise portals or high-traffic WooCommerce stores requires precision. To ensure zero data loss and absolute architectural integrity, leveraging professional WordPress Multisite Development Services is the most secure path to scale your network.

Conclusion

Migrating a standalone WordPress installation into a Multisite network provides the definitive architectural foundation for B2B agencies to scale server resources efficiently. By enforcing a sterile database consolidation process, precisely renaming table prefixes, and securing file upload paths, you eliminate redundant maintenance tasks.

Mastering the use of WP-CLI for dry-run testing and executing raw SQL merges via tools like TablePlus guarantees absolute control over your network environment. Execute domain mapping protocols meticulously with SNI validation to ensure client branding and SSL security remain uncompromised throughout the enterprise ecosystem.

Frequently Asked Questions (FAQ) on WordPress Multisite Migration

Can I migrate an existing WooCommerce store into a Multisite network?

Yes, but you must isolate and prefix all WooCommerce-specific custom tables (e.g., wp_woocommerce_order_items) manually. Standard export files cannot handle the relational database complexities of an active eCommerce store, making direct SQL manipulation mandatory.

Do I need a dedicated IP address for WordPress Multisite domain mapping?

No. Modern server environments utilize Server Name Indication (SNI), which allows a single IP address to serve multiple mapped domains, each secured with its own distinct SSL certificate.

Will migrating to Multisite affect my SEO rankings?

Search rankings remain stable provided you execute comprehensive 301 redirects and ensure your DNS propagation occurs rapidly. If you utilize native domain mapping to retain the exact legacy URL structure, search engines will detect zero architectural changes at the frontend level.

How do I handle users who had accounts on the old single site?

You must extract the users from the legacy wp_users table and inject them into the network’s global wp_users repository. Subsequently, you must update their meta keys in the wp_usermeta table to grant them capabilities specifically for the new subsite ID (e.g., using wp_2_capabilities).

What is the maximum number of sites a single WordPress Multisite can handle?

A highly optimized Multisite network deployed on dedicated enterprise architecture can support tens of thousands of subsites. The limitations are entirely hardware-based, depending on your database server’s concurrent connection capacity, CPU allocation, and available disk space.

WordPress Architect

Fachremy Putra

WordPress Architect & UX Engineer with 20+ years of experience. Specializing in high-performance enterprise architectures, Core Web Vitals optimization, and zero-bloat Elementor builds.

in 𝕏