Multisite migrations break more than you think—here's why
The staging server hums quietly in a Berlin data centre while you sip lukewarm coffee at 2 a.m., watching progress bars inch across the screen. The multisite export finished twenty minutes ago. The import is about to teach you what WordPress doesn’t migrate cleanly.
WordPress multisite breaks in three places when you move hosts—and staging won’t warn you
URL mappings, media paths, and subdomain DNS all fail silently during multisite migrations.
Single-site WordPress migrations are predictable. You export the database, update two URLs in wp_options, upload files, and you’re live. Multisite installs multiply the surface area. Each subsite stores its own domain mapping in wp_blogs and wp_domain_mapping. Media libraries reference the old host in wp_X_posts (where X is the blog ID). Subdomain DNS assumes you control the zone file at the new registrar. None of this breaks during export—it breaks when the first editor tries to upload an image or a reader hits a mapped domain.
The database find-and-replace that works for single sites misses multisite because table names are dynamic. Search-replace tools like Better Search Replace or WP-CLI will update wp_posts, but they won’t touch wp_2_posts, wp_3_posts, and so on unless you explicitly enumerate every subsite table. Domain mapping plugins (Mercator, WordPress MU Domain Mapping) cache old URLs in their own tables. If you migrate without flushing those caches and updating the plugin’s settings, mapped domains return 404s while the primary domain works fine. Your staging environment won’t catch this because staging rarely replicates custom domain mappings or live DNS.
Media paths fail because WordPress stores the upload URL as an absolute path in each subsite’s wp_X_options table (upload_url_path and upload_path). If your old host used /wp-content/uploads/sites/2/ and your new host uses /public_html/wp-content/uploads/sites/2/, every image link breaks until you update both the database and the file structure. Subdomain DNS breaks because multisite assumes you’ve created A or CNAME records for every subsite subdomain. Cloudflare, Route 53, and cPanel DNS editors all handle wildcard records differently. Miss one configuration step and half your subsites load while the others time out.
RELATED
WordPress media search only indexes filenames—not the metadata you think it does
After a multisite migration, operators often discover that the media library search returns nothing—or worse, returns the wrong images. WordPress media search doesn’t index captions, folder structure, or EXIF data. It only searches filenames and alt text. If your migration renamed files (common when hosts strip special characters or flatten directory structures), your internal search breaks silently. Editors waste hours hunting for assets they know exist. The fix isn’t a plugin—it’s understanding what WordPress actually indexes and adjusting your upload workflow before the next migration.
TACTIC
Changing wp_ table prefixes sounds secure but complicates every migration
Security checklists still recommend changing WordPress’s default wp_ database prefix to something custom—wp_a8f3_ or similar. The theory: attackers who hardcode table names in SQL injection payloads will fail. The reality: modern attacks enumerate tables dynamically, so a custom prefix buys you nothing. What it does cost you is compatibility. Migration plugins, staging tools, and manual database imports all assume wp_ by default. Multisite migrations compound the problem because each subsite adds numbered tables. If you’ve already changed the prefix, you’re editing migration scripts by hand. If you haven’t, skip it. The security upside is theatre; the operational downside is real.
FROM THE ARCHIVE
admin-ajax.php hammers your server during high-traffic moments—here’s why
Once your multisite migration is live, you’ll notice server load spikes that didn’t exist on the old host. The culprit is often admin-ajax.php, WordPress’s asynchronous request handler. Every heartbeat check, every autosave, every “load more” button on the front end fires a POST to admin-ajax.php. Poorly coded plugins queue dozens of simultaneous requests. On shared hosting or undersized VPS instances, this creates a bottleneck. Your new host’s architecture might handle static files beautifully but choke on PHP concurrency. The fix involves auditing which plugins use admin-ajax, replacing the worst offenders, and—if you’re on a VPS—tuning PHP-FPM worker limits.
Know someone who would like this? Forward today’s email—every operator we reach is one closer to running an online business with a little less friction.