Migration went wrong
A migration doesn't fail all at once. It fails in layers.
A WordPress move is four migrations wearing one name — files, database, URLs, DNS — and each can fail independently. That's why broken migrations look so strange: the homepage works but images are gone, or the site loads but links point at the old domain, or two versions of your site answer depending on who's asking.
Same-day diagnosis. Flat quote before any fix.
What’s actually happening
Understanding the four layers turns chaos into a checklist. Files (themes, plugins, uploads) can copy incompletely. The database can arrive with its serialized data mangled by a bad search-replace. URLs can keep pointing at the old home, sending visitors and assets back across the gap. And DNS can split the audience — half the internet seeing the new server, half the old — for hours or days, which is how you and your customer can look at 'the same site' and see different things.
The layered failure is also why panicked re-migrating usually deepens the hole: re-running a move atop a half-completed one mixes eras of files and database rows into something neither host recognizes. The professional approach freezes the situation, identifies which layer broke, and repairs that layer — the other three usually arrived fine.
The usual causes, ranked
After twenty-seven years of these calls, the odds are well mapped. Start at the top.
The search-replace mangled serialized data
WordPress stores settings in length-prefixed serialized strings; a naive URL find-and-replace breaks the prefixes and corrupts widgets, builders, and options. The classic silent wrecker.
Incomplete file transfer
Timeouts mid-copy leaving uploads or plugin folders partial — the site runs, but images 404 and one plugin fatals.
URLs still pointing home
siteurl/home still naming the old domain, or hardcoded links throughout content — the new site keeps handing traffic back to the old one.
DNS split-brain
Propagation serving old and new servers simultaneously — orders landing on a server nobody's watching, edits appearing and vanishing.
What you can safely try first
Nothing below can make things worse — that’s the selection criterion. Anything riskier belongs in professional hands, on a backup.
- 1
Stop migrating
The strongest move mid-disaster is to stop moving. Note exactly what was run, in what order, with which tool — that sequence is the diagnosis.
- 2
Establish which site you're looking at
Compare a page you recently edited against both hosts' file dates, or check DNS from a propagation checker. Half these mysteries are two servers wearing one domain.
- 3
Keep the old host alive
Whatever you do, don't cancel the source hosting yet. It's your working backup and the reference for every repair. Cancellation is the one migration mistake with no undo.
Stop and call when…
- Serialized-data corruption — repairing it takes tooling, not a text editor
- Orders or form leads are arriving on both servers — every hour of split-brain is data to reconcile
- The old host's billing cycle ends soon — get the rescue done while the source still exists
From there it’s our job: same-day look, flat quote, and the $229 flat repair covers most cases of exactly this.
Single Error Fix — buy it now, skip the hunt.
One error, hunted down and fixed — 500s, white screens, redirect loops, broken pages.
Covers one specific error or broken behavior on one site. Diagnosis, the fix, and a plain-English note on what happened. If we can't fix it, you get a full refund.
Questions we hear a lot.
Can a half-broken migration be finished, or do we start over?
Almost always finished. The layers that arrived intact stay; the broken layer gets repaired or re-moved on its own — files re-synced, database re-exported with a serialization-aware replace, URLs corrected in place. Starting over discards the layers that worked and re-rolls the dice on all four.
Why do my images 404 when every page loads fine?
Pages live in the database; images live in files. Your database made the trip and your uploads folder didn't finish — the classic mixed outcome of a timeout mid-transfer. It reads as 'the site half-works,' but really one of the four layers is simply missing.
The mover plugin said 'success.' How is the site broken?
The plugin means its transfer completed — it can't know that serialized data survived, that DNS points where you think, or that the copy it made was of the version you intended. 'Success' is the beginning of verification, not the end of it. The flat fix includes the verification pass migrations should always get.
Related symptoms & help
Errors travel in packs. If this one visited, check its friends.
Land the move you started. Same-day triage.
Send the symptom, get a same-day look and a flat quote from the developer who's fixed this exact thing more times than either of us can count.