How to Roll Back a Migration When the New Host Turns Out Worse

To roll back a hosting migration, you switch DNS back to the old server and keep it there until the new one is proven, which only works if you planned the reversal before you started. The rollback is mostly a DNS and data problem, so the preparation matters more than the panic. Treat the old host as a live standby rather than a thing you left behind, and the reversal becomes a controlled operation instead of an emergency.

This guide is about the mechanics of a roll back hosting migration that has gone wrong: the record change, the cache behaviour, the data you have to bring back, and how to test it before real users see it.

Before you move: what makes a roll back hosting migration possible

The most common cause of a painful rollback is a TTL set to a large value days before the move "to reduce load". That is the wrong instinct. Lower the TTL on the records you are about to change well ahead of the cutover, so that by the time you flip them the old value has expired from resolvers. A short TTL costs you a little more query traffic and buys you the ability to reverse in minutes rather than hours.

Keep the old hosting account active and paid up until the new server has run cleanly for a period you decide in advance. Do not cancel it on cutover day. Keep the old DNS zone intact so you can restore it by pasting it back, and keep a copy of the zone file outside both hosts:

dig +short AXFR example.com @ns1.old-host.example
dig +short example.com A
dig +short www.example.com CNAME

Write down what "worse" means before you start, in measurable terms: error rate from your access logs, response time from a monitor you control, mail delivery failures, or database latency. A rollback decision needs a threshold, not a feeling. Decide who has authority to call it and how they will communicate it.

Running the rollback

The core action is changing the DNS records back to the old server's addresses. If your registrar or DNS provider keeps the previous record set, restore it; otherwise edit the A and AAAA records and any CNAME records that pointed at the new host. Change the apex record and the www record together, and do not forget mail: if MX records moved, put them back, and check TXT records such as SPF if they referenced the new provider.

$TTL 300
@   IN A     203.0.113.10
www IN CNAME @
@   IN MX 10 mail.example.com.

If you control the zone through an API, script the change so the same correct record set is applied every time and you are not hand-editing under pressure. Whatever the mechanism, verify propagation from more than one resolver rather than trusting your own machine's cache:

dig +short example.com A @1.1.1.1
dig +short example.com A @8.8.8.8
dig +short example.com A @ns1.old-host.example

Clients that already resolved the new address will keep using it until their cached TTL expires, so the rollback is not instant for everyone. That is exactly why the TTL was lowered beforehand. If you cannot wait, the only lever is the new server itself: put it into a state where it redirects or proxies back to the old one, or stop serving on it, so stragglers fail over rather than failing. A temporary 301 from the new host to the old hostname moves people back as their caches drain.

Once DNS points at the old server, confirm the application is actually healthy there, not just reachable. Check the site over HTTPS, check a login, check that sessions and uploads work, and watch the error log for the first while. Health checks that only test the home page will not catch a broken checkout.

Bringing data back without losing writes

This is where rollbacks get ugly. If the site took writes on the new server (orders, comments, uploads, user registrations), those writes exist only on the new host. Reverting DNS does not move them. Before you switch back, decide whether you need to reconcile that data, and if so, freeze writes on the new server first so nothing new arrives while you copy.

Dump the new database, load it into the old one, and be honest about conflicts: rows inserted on both sides need a rule for which wins, and that rule is application specific. For files, sync the upload directories back and check timestamps. Test the restore on a copy before you point anything at it. If reconciliation is too risky, the alternative is to keep the new server serving reads only, or to lose the window of writes deliberately and tell affected users. Choose that in advance, not at the moment of failure.

After the rollback

Leave the new host running for a while so you can inspect logs and understand what went wrong, then shut it down cleanly. Keep the old server's configuration under version control so the next attempt starts from a known state. Restore the DNS TTL to its normal value once you are settled, and write the rollback steps into a runbook with the exact commands, the record names, and the decision threshold, because the next person to run it may not be you.

Test the whole procedure on a staging hostname before you trust it: move a copy of the site to a throwaway name, then roll it back using only the runbook. If that takes longer than you would tolerate during an outage, fix the runbook now, while nothing is on fire.