WordPress Multisite Migration 2026: 5 Real Crashes From Single Site to Network

I recently helped a client consolidate 7 standalone WordPress sites into one Multisite network. I thought it would be a 3-minute job — flip a constant, run a setup wizard — but the first week hit 5 production crashes: subsite whitescreens, cookie domain mixups, upload_path silently overwriting the main site's images, and WP-CLI commands that "succeeded" but did nothing. This article walks through the exact incident timeline so you don't pay the same tuition.

🛠️ Prerequisites

Baseline:

• WordPress 6.9.1 (2026-02-03 maintenance release; Multisite API stable since 6.0, 6.9 behavior unchanged)
• WP-CLI 2.11.x + PHP 8.2 + MySQL 8.0 / MariaDB 10.11
• Server: single VPS, 2GB+ RAM (each subsite adds ~20-50MB PHP resident)
• DNS: wildcard `*.example.com` required for subdomain mode; A record only for subdirectory mode
• Backup: full DB + uploads dir

# Full backup
wp db export /backup/full_$(date +%F).sql --allow-root
tar czf /backup/uploads_$(date +%F).tar.gz wp-content/uploads

Step 1: Pre-flight Checklist Before Enabling Multisite

WordPress Multisite is not a toggle — it's a **permanent architectural decision**. Reverting leaves orphaned wp_blogs / wp_signups tables. Pre-flight checklist:

1. **Plugin compatibility**: wp plugin list --allow-root and verify each plugin declares "Network: true". Common offenders: older Yoast SEO, W3 Total Cache, legacy Jetpack versions

2. **uploads dir cleanup**: Existing wp-content/uploads/2024/ folders must be migrated first. After Multisite, uploads go to wp-content/uploads/sites/{blog_id}/

3. **DB prefix consistency**: Multisite tables (wp_blogs / wp_blog_versions / wp_registration_log / wp_signups / wp_site / wp_sitemeta) are **NOT auto-created** — WordPress writes them only on first visit to Tools → Network Setup

4. **Domain commitment**: Once example.com is the main site, switching later means full rewrite of wp_site / wp_blogs rows

Step 2: Enable Multisite (Two Trivial Steps That Go Wrong)

Add to wp-config.php (**before /* That's all... */ comment**):

define('WP_ALLOW_MULTISITE', true);

Refresh admin, go to Tools → Network Setup:

• **Subdomains** (recommended for production): `site1.example.com`, needs wildcard DNS + wildcard SSL
• **Subdirectories** (new sites only): `example.com/site1/`, no DNS work but bad for SEO

After Install, you'll get two code blocks. **Block 1** → wp-config.php:

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

**Block 2** → .htaccess (Apache) or Nginx try_files rewrites (Nginx recommended). Forgot the web server config = all subsites 404.

💣 5 Real Crash Scenarios

Pitfall 1: wordpress-mu-domain-mapping + SUNRISE ordering chaos

**Symptom**: After activating Domain Mapping plugin, all subsites whitescreen with Use of undefined constant SUNRISE.

**Root cause**: Plugin requires define('SUNRISE', true); in wp-config.php. WordPress core reads this during MU plugins loading — if your SUNRISE line sits after /* That's all, stop editing! */, certain plugin load orders can silently ignore it.

Fix:

// wp-config.php — SUNRISE must come before MU plugin load
define('SUNRISE', true);
define('DB_COLLATE', '');
define('AUTH_KEY', '...');
// ... other constants

// Verify with WP_DEBUG
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

**Prevention**: Always put SUNRISE at the top of wp-config.php, before ABSPATH.

Pitfall 2: Cookie domain config broken → instant logout / cross-site login

Symptom: Log in to subsite A, refresh → bounced back to login. Open subsite B in same browser → see A's admin bar.

**Root cause**: WordPress default cookie domain is example.com; subsites should share it. If wp-config.php has a leftover define('COOKIE_DOMAIN', 'www.example.com');, cookies fail across subsites.

Fix:

// Remove explicit COOKIE_DOMAIN (let WP use DOMAIN_CURRENT_SITE)
// Or, correct form:
define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST']);
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');

**Prevention**: Before enabling Multisite, grep COOKIE wp-config.php and delete any explicit COOKIE_DOMAIN.

Pitfall 3: upload_path unchanged → subsite uploads overwrite main site images

Symptom: Upload image on subsite, filename collision, main site's image silently overwritten.

**Root cause**: Multisite activation does NOT change wp_options.upload_path. Each new subsite inherits the main site's value and writes to wp-content/uploads/ until manually fixed.

Fix (one-shot via WP-CLI):

# Main site — keep
wp option update upload_path 'wp-content/uploads' --allow-root

# Subsites (look up blog_id from wp_blogs)
wp --url=site1.example.com option update upload_path 'wp-content/uploads/sites/2' --allow-root
wp --url=site1.example.com option update upload_url_path 'https://site1.example.com/wp-content/uploads/sites/2' --allow-root

**Prevention**: After each wp site create, run all three lines above immediately.

Pitfall 4: WP-CLI silently no-ops on subsite config changes

**Symptom**: wp option update blogname 'New Name' --url=site1.example.com --allow-root returns Success, but admin shows old name.

**Root cause**: WP-CLI in Multisite mode requires --url= for context switching. Some commands (e.g. wp post create) additionally require --network or the wp site subcommand.

Fix:

# Wrong: "Success" but no effect
wp option update blogname 'New Name' --allow-root

# Right: explicit subsite URL
wp option update blogname 'New Name' --url=https://site1.example.com --allow-root

# More reliable: list sites first
wp site list --allow-root

# Cross-network operations: must include --network
wp post list --post_type=product --network --allow-root

**Prevention**: Always pass --url= to any single-subsite WP-CLI command.

Pitfall 5: No Wildcard SSL → all subsite HTTPS broken

**Symptom**: Main site https://example.com works. Every https://site1.example.com shows NET::ERR_CERT_COMMON_NAME_INVALID.

**Root cause**: Let's Encrypt single cert covers example.com + www.example.com only. Subsites need wildcard *.example.com.

Fix (Certbot + Nginx):

# One-time wildcard cert (requires DNS TXT challenge)
certbot certonly --manual --preferred-challenges=dns \
  -d example.com -d "*.example.com"

# Nginx: ssl_certificate must point to wildcard cert
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

# Auto-renewal: requires re-adding DNS TXT record
# Use acme-dns or certbot-dns-cloudflare plugin to automate

**Prevention**: Issue wildcard cert **before** switching to Subdomain Multisite. Use acme.sh + Cloudflare API for fully automated renewal.

🛡️ Advanced: Multisite Performance & Backup

After Multisite is on, each subsite's wp_posts / wp_postmeta are **separate tables** (not partitions!), but wp_options stays **shared across the whole network** — so wp_options autoload bloat gets amplified.

# Network-wide backup (must include --network)
wp db export /backup/network_$(date +%F).sql --allow-root

# Restore single subsite (precise, no impact on others)
# 1. List tables for blog_id=2
# 2. Dump only those + shared wp_users

Advanced tuning:

• **Shared object cache**: Redis Object Cache with `WP_CACHE_KEY_SALT` per network
• **CDN for media**: WP Offload Media plugin to keep uploads off the VPS
• **Lock site IDs in wp-config**: prevent accidental main-site deletion

Summary and Next Steps

Multisite is the right answer for "manage N sites with 1 core", but the pre-flight checklist and the 5 post-launch fixes have to be in your head before you start. Next time I do a client migration, I'll send the "Pre-launch 10 checks" + "Post-launch 30-min fix script" as a contract appendix, so the potholes are paved before we hit them.

If this is your first Multisite, practice on localhost.wp with Subdirectory mode. Don't jump straight to Subdomain + Wildcard SSL — the 5 pitfalls above will all hit you at once.

Related reading: WordPress Database Migration: 3 Real Pitfalls and Fixes (primer for Multisite data layer work) and WordPress Nginx Configuration Complete Troubleshoot (web server rewrites required for Multisite).

👉 Join MiniMax Token Plan: AI coding acceleration for businesses

👉 Join Zhipu Coding Plan: GLM-4.6/GLM-5 coding packages, China-stable, pay-per-token unlimited

👉 Join Aliyun AI: Top AI products with exclusive coupons for business innovation

📌 This article was AI-assisted generated and human-reviewed | TechPassive — An AI-driven content testing site focused on real tool reviews