Anatomy of a Website Migration Gone Wrong — and How to Move a Revenue Site Safely

When your website is the business, a migration is open-heart surgery. Move it carelessly and the bill is never just the project cost — it is every order you did not take while things were broken, every ranking you quietly lost, and every customer who tried to buy, failed, and went to a competitor instead.

Migrations go wrong far more often than anyone admits. Here is how the damage actually happens, and how to make sure it does not happen to you.

What a bad migration really costs

The invoice for the migration is the smallest number involved. The real costs show up elsewhere:

• Lost sales during downtime. For a site doing real revenue, an afternoon offline is not an inconvenience — it is money that never arrives, and it does not come back.
• A checkout that silently breaks. The homepage looks fine, so everyone relaxes — while the payment step throws an error on mobile and nobody notices for three days.
• An SEO cliff. Miss the redirects and you hand years of accumulated rankings back to zero. Traffic — and the revenue attached to it — falls off a cliff and takes months to recover.
• Data loss. Orders, customer records or content that existed the day before launch and simply are not there the day after.

Why migrations fail

Almost every migration disaster traces back to the same handful of shortcuts:

• No staging environment. Changes get tested in production, on live customers.
• A big-bang cutover. Everything switches at once, with no way to move back if something breaks.
• No backup — or a backup nobody tested restoring. An untested backup is a rumour, not a safety net.
• Ignored redirects. Old URLs 404 instead of pointing at their new homes, and the search engines punish it.
• An untested checkout. Forms and payment flows are assumed to work rather than proven to work, on every device.
• DNS with a long TTL. The cutover drags out for hours because the old records refuse to expire.
• No rollback plan. When something does go wrong, there is no fast, rehearsed way back to safety.

The safe-migration checklist

This is the discipline that turns a high-risk move into a non-event:

1. Build a real staging replica. A full copy of the site where every change is proven before it goes anywhere near customers.
2. Take full backups — and test the restore. Database, files, and configuration. Restore them somewhere to confirm they actually work.
3. Map every redirect. A 301 from every old URL to its new equivalent, so rankings and links survive intact.
4. Preserve URLs and metadata wherever possible — the less the structure changes, the less there is to lose.
5. Test checkout and every form on staging — on desktop and mobile, with a real transaction end to end.
6. Lower DNS TTL in advance so the cutover is minutes, not hours.
7. Cut over off-peak, when the fewest customers are on the site.
8. Watch it live. Uptime, error rates and the checkout funnel monitored from the moment you go live.
9. Keep the old version warm and a rollback ready, so “undo” takes minutes if you need it.
10. QA after cutover, not just before — the bugs that matter often only appear on the real environment.

The bottom line

A migration should be the most boring day of the quarter. When it is dramatic, it is because a step on that list was skipped. The businesses that move platforms without losing a sale are not lucky — they are the ones who treated a revenue-critical site like the asset it is.

That is exactly the kind of move we run, and the kind of disaster we help prevent and recover from. If a migration or replatforming is on your horizon, talk to us before it becomes a story you tell later.