WordPress multisite migration isn’t the same as moving a single-site install. The network architecture means your database holds cross-site references, your media library spans domains, and your DNS has to route traffic through the primary domain before handing off to subsites.
If you’ve ever moved a multisite network to a new host and watched half your images vanish or login redirects break, you know the pain. Here’s what actually breaks, what survives the move, and how to fix the common failure points before they cost you traffic.
URL mappings break first
Multisite stores site URLs in wp_blogs and wp_site tables. When you migrate, your old domain references stay hardcoded unless you run a search-and-replace across the network database.
If you’re running subdomain multisite (like site1.yourdomain.com), every subsite has its own domain entry in wp_blogs. A standard WP migration plugin won’t catch these—it only updates siteurl and home in wp_options for the primary site.
Run a network-wide search-and-replace using WP-CLI’s search-replace command with the --network flag, or use a plugin like Better Search Replace in network mode. Target the old domain string and replace it with the new one across all tables. Don’t skip serialized data—WordPress stores arrays and objects in the database, and a partial string replacement corrupts them.
Media library paths don’t update automatically
Multisite stores uploaded files in /wp-content/uploads/sites/{site_id}/ directories. When you migrate, the files move with the server, but image URLs in post content and media library metadata still point to the old domain.
Your search-and-replace will catch most of these if you’re thorough. But if you’re moving from HTTP to HTTPS, or changing the subdirectory path (like moving from /blog/ to root), you’ll have orphaned image references that don’t render.
Check wp_posts.guid and wp_postmeta for _wp_attached_file and _wp_attachment_metadata keys. These hold the full image paths and need manual correction if your directory structure changed. A broken guid won’t stop images from displaying, but it will break media library searches and attachment page URLs.
Subdomain DNS has to route through the primary domain
If you’re running subdomain multisite, your DNS needs a wildcard A record pointing *.yourdomain.com to your server IP. When you migrate hosts, that wildcard has to update to the new IP—and if your DNS propagation is slow, subsites will be unreachable even after the primary domain resolves.
Check your DNS panel and confirm the wildcard record exists and points to the correct IP. If you’re using Cloudflare or another proxy, make sure the wildcard is set to DNS only (gray cloud) during migration, not Proxied (orange cloud). Proxied wildcard records can break subsite routing if the SSL certificate doesn’t cover all subdomains.
If you’re moving to a managed WordPress host like BigScoots, ask support whether they handle wildcard DNS automatically. Some hosts provision it; others require manual setup.
Plugin network activation states don’t transfer cleanly
Multisite lets you activate plugins network-wide or per-site. When you migrate, the wp_sitemeta table holds network activation data, and wp_{site_id}_options tables hold per-site activation.
If you’re moving between hosts with different PHP versions or server configurations, plugins that worked network-wide on the old host may fail silently on the new one. Check the active_sitewide_plugins key in wp_sitemeta after migration and deactivate any plugins that throw errors in the WordPress admin.
Some plugins—especially caching and security plugins—store server paths in their settings. If your new host uses a different document root (like /var/www/html/ instead of /home/username/public_html/), those plugins will break until you regenerate their config files.
What actually survives the move
Your post content, user accounts, and plugin settings all migrate cleanly if you’re using a proper database export. The wp_users and wp_usermeta tables are network-global, so user logins work across all subsites immediately after the move.
Theme files and uploads transfer intact if you copy the entire /wp-content/ directory. Just make sure file permissions are set correctly on the new host—644 for files, 755 for directories. If your new host uses a different user/group (like www-data instead of nobody), you’ll need to chown the files or uploads will fail.
Test before you flip DNS
Before you point your domain to the new host, test the migration using your server’s temporary URL or by editing your local /etc/hosts file to map your domain to the new IP.
Log in to the network admin, visit a few subsites, upload a test image, and check whether plugins activate correctly. If anything breaks, you can fix it without taking the live site offline.
Once you’re confident, update your DNS A records, wait for propagation, and flush any page caches. Multisite migrations take longer than single-site moves, but if you catch the URL mappings, media paths, and DNS routing, the network will come up clean.
Got a multisite migration story? Reply with what broke for you—we’ll cover edge cases in a future issue.