Quick answer: Rolling back is just pointing DNS back at the old server — IF the old server is still running and IF no meaningful data was written to the new one. That is why you keep the old service alive after cutover and why write-heavy sites reconcile data before rolling back. Decide your rollback rules before you migrate, not during the incident.
Overview
A rollback is not failure; it is the safety mechanism that makes bold cutovers safe. The catch is data: from the moment DNS switched, new orders, posts and uploads may exist only on the new server. A clean rollback therefore has two parts — the easy DNS step and the careful data-reconciliation step.
Before you start
- The old server still intact and running (the golden rule of cutovers).
- Knowledge of what writes happened since the switch: orders, registrations, uploads, comments.
- Low DNS TTL still in effect from the migration, so the switch back propagates fast.
Step-by-step guide
- Decide fast, calmly: a rollback is warranted for functional breakage you cannot fix quickly — not for a styling glitch.
- Freeze writes on the new server (maintenance mode) so the divergence stops growing.
- Export the delta: pull anything created since cutover from the new server — database rows since the switch timestamp, uploaded files by date.
- Import the delta into the old server and verify the merged state (for stores: order IDs continuous, no duplicates).
- Switch DNS back to the old IP and confirm with
dig +short. - Post-mortem before retry: fix the root cause on the new server, re-test via hosts file, then schedule a new cutover.
Common issues
- Old server already cancelled: then there is nothing to roll back to — this is why the old service outlives the migration by days.
- Skipping reconciliation: rolling DNS back without merging the delta silently discards real customer data.
- Flip-flopping: switching back and forth within hours multiplies cache confusion — roll back once, fix properly, re-cut once.
When to contact support
If you are mid-incident and unsure whether data diverged, open a ticket marked urgent with both servers' details — an engineer can help you compare states before you make the call.
Frequently asked questions
When should I roll back instead of fixing forward?
Roll back for functional breakage you cannot fix within your tolerance window: broken checkout, data errors, hard downtime. Cosmetic issues are fixed forward on the new server.
What happens to data created after the DNS switch?
It lives only on the new server, so export the delta — orders, users, uploads since the switch timestamp — and merge it into the old server before pointing DNS back.
Does a rollback mean the migration failed for good?
No. It buys you time to fix the root cause calmly, re-test via hosts file and schedule a clean second cutover — much better than debugging in production under pressure.
Related articles
- How to avoid downtime during migration
- Common migration issues
- Post-migration checklist
- How to migrate WooCommerce without losing orders
Need a hand with your move? Contact Cloud2Y support →
