Rollback plan after a broken site migration

A well-run migration almost never needs a rollback. But the few that do go badly go badly fast, and every minute the site is broken costs traffic and trust. The difference between a bad afternoon and a multi-day outage is usually a rollback plan that was written and tested before the cutover, not the skill of the person doing the move.

Why a rollback plan is essential

A rollback returns the site to the environment that was working immediately before the cutover. It is not a backup restore of the whole world: it is a narrow, rehearsed path back to your previous host, database, DNS, and SSL state.

The most common reason migrations fail is not server errors. It is losing the path back. People rename files, drop databases, cancel the old host, or change DNS TTLs to very low values and cannot remember what the previous state looked like. A rollback plan fixes the main risk: you never reach an irreversible state without knowing your exit.

Build the plan before you start

Do the groundwork while the old site is still fully working.

• Record every moving part: old and new host IPs, the document root path, database credentials, the exact DNS record set, and the SSL certificate source and expiry.
• Take a final full backup of the old environment: database plus all files, with the checksums or modified dates noted. Store it off-server, not on the host you may be abandoning.
• Check the live DNS before you touch anything. Note the current TTL, A/AAAA/CNAME records, and any third-party records for email (MX, SPF, DKIM) so a rollback can restore them exactly.
• Agree the rollback trigger in writing: the same errors for more than 20 minutes, data loss detected, or a specific checkout or login failure. A trigger decided under stress is a bad trigger.

Write the rollback steps in order and keep a copy outside the hosting panel, for example in a password manager or a private file.

Execute the rollback safely

Run the rollback rather than repairing forward when the failure is broad or data is at risk.

1. Point DNS back to the old host first, and follow the exact record set you recorded. Lowering TTLs speeds every later switch only if you also lower them before the failing cutover; do not change them mid-rollback.
2. Restore the old database and files from the backup you took before the move. The goal is to return to a known-good state, not to blend old and new content.
3. Confirm the old SSL certificate still covers the domain, is not expired, and its key and files are intact on the old host.
4. If email moved in the same migration, restore the old MX and authentication records and flush any new records that pointed elsewhere.

Verify after the rollback

Do not call it done because the homepage loads.

• Run the same checklist the cutover used: a couple of key pages, the checkout or form flow, logins, and any scheduled jobs.
• Check that links, redirects, and canonical URLs resolve, because a broken internal link is easy to miss in the panic.
• Watch the error log for a few minutes and confirm requests are back at normal volume and no residual 502 or database errors appear.
• Review why the migration failed before retrying. A rollback that replays the same configuration mistake will just break again. See move website to new hosting topics for a safer retry.

Prevention

Keep the rollback plan as a living document during every future move. Do a dry run of the restore against a staging copy so that when a real rollback is needed, the commands and passwords are proven, not guessed. A plan that is rehearsed is a plan that works.