Blog / hosting
Why hosting migrations go wrong (and how mine don't)
Fifteen years inside hosting companies taught me that failed migrations are predictable: DNS TTLs, email cutover, and untested restores.
I spent about fifteen years inside hosting companies, and a good chunk of that time was spent watching migrations succeed or fail. The failures were rarely exotic. Nobody got taken down by a kernel bug or a data centre fire. Migrations go wrong the same four or five ways, every time, and every one of those ways is preventable if someone bothers to plan for it.
Here are the ones I saw over and over, and what I do differently.
DNS is a schedule, not a switch
The single most common migration mistake is treating DNS like a light switch. You point the domain at the new server, and you assume the world follows instantly.
It doesn't. Every DNS record carries a TTL, a "time to live" that tells the rest of the internet how long to cache the old answer. If your TTL is 24 hours, some visitors will keep hitting the old server for a full day after cutover. If the old server has already been cancelled, those visitors see an error page. If it's still running, they see stale content, or worse, they submit orders and form entries to a database you've stopped watching.
The fix costs nothing: lower the TTL to five minutes a couple of days before the move, cut over, confirm everything, then raise it back. I have never seen a botched cutover where this was done properly. I have seen plenty where nobody checked the TTL at all.
Email is where migrations get personal
A website that's down for an hour is embarrassing. Email that silently vanishes for a weekend can be a legal problem.
During the DNS propagation window, some mail servers deliver to the old box and some to the new one. If nobody plans for that split, messages land on a server no one is checking, and they're often gone for good when the old account is closed. The safe pattern is boring: sync the mailboxes to the new server first, keep the old server receiving until propagation is genuinely complete, then sync again to sweep up stragglers before anything gets cancelled.
Also worth saying plainly: check that every mailbox actually moved. The owner's inbox always makes the list. The accounting@ alias that only gets mail at month end is the one that gets forgotten.
The untested restore
Every migration plan says "we have backups." Almost none of them say "we have restored from those backups and confirmed the result works."
Those are very different claims. I've seen backup archives that were silently truncated, database dumps taken mid-write, and backup jobs that had been failing quietly for months while the dashboard showed green. The time to discover any of that is before the migration, not at 2 a.m. when the new server won't come up and the old one is gone.
My rule: the migration hasn't started until a full restore has been tested somewhere disposable. If the restore works, the migration is mostly logistics. If it doesn't, you just found out while it was still cheap to know.
Freeze windows, and who ignores them
A migration copies your site at a moment in time. Anything that changes after the copy and before the cutover exists only on the old server: new orders, new posts, password changes, uploaded files.
That's why serious migrations have a content freeze, a short window where everyone agrees not to touch the site. The plan falls apart when the freeze is announced but not enforced, usually because one person didn't get the memo and kept editing. For busy sites where a freeze isn't realistic, the answer is a second differential sync at cutover time, not crossed fingers. Either way, it has to be decided up front, which is really a scoping conversation before it's a technical one.
Most of this is free to get right
None of the above requires expensive tooling. It requires someone who has done it enough times to know where the bodies are buried, and a written plan with an order of operations and a rollback point.
It's also worth knowing that many reputable hosts will do the heavy lifting at no charge. DrivenHost, for example, includes free migrations, and a host that handles moves in-house every day is far less likely to trip on the basics than someone doing their second one ever. The catch is that the host migrates the site; the DNS timing, the email overlap, and the go/no-go decision are still yours to own.
If you have a move coming up and you'd rather it be boring, that's exactly the kind of thing I plan for people. A migration should be an anticlimax, and an hour or two of hosting advice up front is the cheapest insurance you can buy for one.