The seven things that go wrong in migrations

Migrations rarely fail in interesting, unpredictable ways. Nearly every bad one comes down to a small set of causes, repeated across thousands of sites, and every one of them is avoidable once you know to look for it.

1. DNS was switched before the new server was ready

The single most common cause of an actual outage. The domain starts sending visitors to a server that is missing files, has the wrong database credentials, or was never fully tested — and there is no quick way back except pointing DNS somewhere else and waiting for that change to spread too. The fix is entirely procedural: test the new server privately, using a hosts file entry, before DNS ever changes. See previewing a site with your hosts file.

2. The old hosting was cancelled too early

DNS does not update everywhere at once. Some visitors' networks are still resolving to the old server for hours, occasionally days, after the switch. Cancel the old account the same day and those visitors get nothing, even though the new server is working perfectly. Keep the old hosting active for about a week after switching, no matter how confident you feel.

3. Hidden files were left behind

Files starting with a dot, most importantly .htaccess, are hidden by default in most FTP clients. A copy that looks complete can be missing the one file controlling redirects, clean URLs, or security rules, and the resulting problems — broken permalinks, unexpected errors — often do not point obviously back to a missing file.

4. Something was forgotten because it was not "in the files"

Email accounts, cron jobs, and custom DNS records for services like site verification are not part of a file or database copy. They live in the old host's configuration and have to be deliberately recreated. This is the category of problem that shows up days after a migration looks finished — a newsletter that silently stopped sending, or a scheduled backup that never ran again.

5. The PHP version did not match

Migrating to a server running a different PHP version at the same time as everything else introduces a second variable into any problem you hit — is it the migration, or the version change? Match the new server's PHP version to the old one first, get the site working, and treat a version upgrade as a separate, deliberate step afterwards.

6. A large database or media library ran out of time or space

Big exports can exceed upload limits, time out mid-transfer, or simply take far longer than expected, especially over a slow connection. Databases too large for a browser-based import have a command-line alternative that avoids the limit entirely — see migrating a very large website for the specifics.

7. Nobody tested the things that actually matter

Loading the home page and declaring the migration a success is the most common shortcut, and the one most likely to leave a real problem undiscovered until a customer finds it. Forms, login, checkout, and the admin area all depend on server-side behaviour that a home page visit does not exercise at all. A proper pre-launch pass — see testing a migrated site before going live — takes an extra half hour and catches almost everything on this list before it becomes visible to anyone else.

Why these seven keep recurring

None of them are exotic. They recur because a migration is a project people do rarely — often once every few years for a given site — so the lessons from the last one have usually been forgotten by the time the next one comes around. A checklist compensates for that gap: it does not rely on remembering what went wrong last time, because the same handful of causes show up whether this is your first migration or your fifth.

If something has already gone wrong

Most of the problems above are recoverable, and having kept the old hosting running is what makes recovery straightforward rather than frightening. See rolling back a migration that went wrong for how to reverse course cleanly if the new server turns out not to be ready after all.

The common thread across a successful recovery is the same one that runs through avoiding the problem in the first place: nothing is final until DNS has switched, and even then the old server stays available as a safety net for about a week. A migration that goes wrong is rarely a crisis if that safety net is still in place — it only becomes one when it has already been removed.