WordPress Migration and Multisite: Advanced Site Architecture

Two technical challenges frequently cause anxiety for WordPress site administrators and developers: executing a flawless server migration without downtime, and architecting a WordPress Multisite network that scales cleanly without collapsing under maintenance debt.

When handled carelessly, both procedures carry severe business risks. A botched database search-replace breaks serialized arrays, leaving themes and custom fields broken. Similarly, choosing Multisite for an incompatible project structure creates an architectural bottleneck where a single plugin conflict or PHP fatal error takes down dozens of web properties simultaneously.

In this technical guide, we break down the engineering principles behind reliable zero-downtime migrations using WP-CLI and explore the multi-tenant architecture of WordPress Multisite.

For more insights into our production infrastructure and development practices, explore our WordPress development services.

#1. Preserving database integrity during migrations

The primary reason WordPress migrations fail is not missing files; it is corrupted database records. WordPress stores a substantial portion of theme options, widget configurations, and plugin data (such as Advanced Custom Fields or page builder layouts) as serialized PHP strings.

#The anatomy of serialized PHP data

Consider how WordPress stores configuration data inside the wp_options table:

a:2:{s:4:"host";s:13:"old-domain.com";s:4:"port";i:3306;}

In this string, s:13 explicitly declares that the string old-domain.com is exactly 13 characters long. If you open a raw .sql file in a generic text editor or run a crude UPDATE wp_options SET option_value = REPLACE(...) query to swap the domain to new-domain.com (14 characters), the length declaration remains s:13.

When WordPress next queries the database and calls unserialize(), the PHP parser encounters 14 characters instead of the promised 13. The parser throws an unserialize(): Error at offset notice, fails closed, and discards the entire array. As a result, widgets vanish, layout options revert to defaults, and API keys disappear.

#The Industrial Solution: WP-CLI search-replace

The official WordPress command-line interface (WP-CLI) natively handles serialization. It pulls objects into memory, deserializes them into PHP data structures, performs the string replacement, recalculates string lengths, and re-serializes the data before committing changes to MySQL:

# 1. Run a dry-run to inspect matched tables and rows without altering data
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run

# 2. Execute precise replacement across all database tables
wp search-replace 'https://old-domain.com' 'https://new-domain.com' \
  --all-tables \
  --precise \
  --recurse-objects

# 3. Flush object cache and regenerate rewrite rules
wp cache flush
wp rewrite flush --hard

#2. Executing a zero-downtime migration protocol

To move high-traffic e-commerce stores or lead generation portals without dropping transactions or confusing search engine crawlers, adhere to this four-phase operational sequence:

#Phase 1: DNS TTL reduction (48 hours prior)

Lower the Time to Live (TTL) on your domain’s DNS A records to 300 seconds (5 minutes). This ensures that global DNS caches refresh rapidly when the new server IP is published.

#Phase 2: Incremental File Synchronization via rsync

Traditional FTP is slow, lacks encryption, and fails silently on large media libraries. Use rsync over SSH to mirror files directly between servers, excluding transient cache directories:

rsync -avzP --delete \
  --exclude 'wp-content/cache/*' \
  --exclude 'wp-content/uploads/cache/*' \
  --exclude '*.log' \
  [email protected]:/var/www/vhosts/site.com/public/ /var/www/html/

The -a flag preserves file permissions and timestamps, while -z compresses data over the wire.

#Phase 3: The Cutover Window

1. Enable maintenance mode on the source server: wp maintenance-mode activate.
2. Generate a clean database dump: wp db export cutover.sql --add-drop-table.
3. Transfer and import the dump onto the new host: wp db import cutover.sql.
4. Run wp search-replace to update site URLs, SSL protocols, or path differences.
5. Verify site health locally by mapping the domain to the new IP in your local hosts file.

#Phase 4: DNS Switch and Verification

Update the DNS A record to point to the new server IP. Because the TTL was reduced to 300 seconds in Phase 1, traffic migrates smoothly to the new host within minutes. Once DNS has fully propagated globally, restore standard TTL (86400 seconds).

#3. WordPress Multisite: multi-tenant architecture

WordPress Multisite enables organizations to manage hundreds or thousands of virtual websites from a single codebase and database instance.

#Multisite Database Architecture

A standard WordPress install contains 12 core tables. In Multisite, WordPress separates global shared data from tenant-specific data:

• Global Network Tables:
  • wp_users and wp_usermeta: User accounts exist globally once across the network. A user can be an Author on Site 1 and an Administrator on Site 2.
  • wp_blogs, wp_site, wp_sitemeta: Track network-level settings, registration policies, and active sites.
• Tenant-Specific Tables:
  • Each child site receives an isolated set of content tables identified by site ID: Site 2 operates on wp_2_posts, wp_2_options, and wp_2_comments.

+-----------------------------------------------------+
|             WordPress Multisite Schema              |
+-----------------------------------------------------+
| Network Global Tables:                              |
| - wp_users / wp_usermeta                            |
| - wp_blogs / wp_site / wp_sitemeta                  |
+-----------------------------------------------------+
| Primary Site (ID 1):                                |
| - wp_posts, wp_options, wp_terms...                 |
+-----------------------------------------------------+
| Subsite (ID 2 - e.g. london.brand.com):             |
| - wp_2_posts, wp_2_options, wp_2_terms...           |
+-----------------------------------------------------+
| Subsite (ID 3 - e.g. paris.brand.com):              |
| - wp_3_posts, wp_3_options, wp_3_terms...           |
+-----------------------------------------------------+

#Strategic Use Cases for Multisite

1. Franchise and Regional Networks: When 100 regional dealerships share the same theme, approved plugins, and core branding, differing only in inventory and localized contact details.
2. Higher Education and Institutional Portals: Giving academic departments and student organizations standardized blogs under an overarching institutional domain.
3. Internal Staging and Product Demos: Instantly provisioning sandboxed sites with pre-installed configurations via automated scripts.

#When to Avoid Multisite

• Diverse Agency Client Rosters: One poorly coded plugin or memory leak on Client A’s subsite can crash the entire PHP process pool, bringing down Clients B, C, and D.
• Divergent Plugin Requirements: If site A requires WooCommerce with complex ERP connectors and site B requires an advanced forum, maintaining a shared plugin directory becomes fragile and prone to dependency conflicts.
• Future Extraction Complexity: Decoupling a single subsite from a Multisite database into an independent standalone site requires exporting filtered SQL tables, rewriting table prefixes, and re-associating users.

#4. Technical configuration and domain mapping

To initialize Multisite, add the authorization directive to wp-config.php:

// Step 1: Enable the network setup menu in the WordPress dashboard
define('WP_ALLOW_MULTISITE', true);

Navigate to Tools > Network Setup in the dashboard, choose between Sub-domains (subsite.domain.com) or Sub-directories (domain.com/subsite/), and paste the generated constants into wp-config.php:

// Step 2: Activate the production network configuration
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);
define('DOMAIN_CURRENT_SITE', 'domain.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

#Native Domain Mapping

Since WordPress 4.5, native domain mapping is baked directly into the core engine. You can map custom top-level domains (e.g. clientdomain.com) directly within Sites > Edit Site in the Network Admin panel without installing third-party mapping plugins. On the web server layer, configure your Nginx or Apache server blocks to accept requests for mapped domains and forward them to the primary WordPress root.