Every database migration plan should answer one question before work starts: if something goes wrong, how do we get back to a working state, and how long will it take? A rollback plan is not a sign of pessimism. It is what makes it safe to proceed, and it often changes how the migration itself is designed.
This guide applies to schema migrations, engine changes (for example MySQL to PostgreSQL) and moves between hosting environments.
Define what "rollback" means for this migration
Rollback can mean different things:
- reverting a schema change with a down migration;
- switching the application back to the old database after a cutover;
- restoring data from a backup or snapshot.
Each has different speed and data-loss implications. Write down which approach applies to each step of the migration, because a single plan rarely fits every step.
Make steps reversible where possible
Design the migration as small steps that can each be undone. Additive changes, such as new columns and tables, are easy to reverse or simply leave in place. Destructive changes, such as dropping columns or tables, cannot be undone without a backup, so schedule them last, after the new system has proven stable.
Verify backups before you start
A backup that has never been restored is an assumption, not a plan. Before the migration, take a fresh backup or snapshot and confirm that it can be restored within an acceptable time on comparable hardware. Record how long the restore took; that number is your worst-case recovery time.
Plan for data written after cutover
The hardest part of rolling back is usually not the schema but the data created after the switch. If users write to the new database for an hour and you then roll back, those writes must be preserved or consciously discarded. Options include:
- keeping the old database in sync from the new one (reverse replication) for a period after cutover;
- logging all writes after cutover so they can be replayed;
- keeping a read-only or maintenance window short enough that the risk is acceptable.
Choose deliberately and document the expected data loss, if any, in each scenario.
Set clear rollback criteria
Decide in advance what will trigger a rollback, so the decision is not made under pressure. Examples include error rates above an agreed threshold, failed data validation checks, unacceptable query latency or a time limit for the migration window. Name the person who makes the call and how the decision will be communicated.
Write the runbook
A rollback runbook lists the exact steps, commands and checks, in order, with the expected result of each. Include how to stop application writes, how to repoint connection strings or DNS, how to verify the old system is healthy and how to re-enable traffic. Store the runbook where everyone involved can reach it during the event.
Rehearse
Run the migration and the rollback in a staging environment that resembles production in size and configuration. Rehearsals reveal missing permissions, slow steps, forgotten scheduled jobs and steps that only exist in someone's head. Time each phase so you know whether the plan fits the window.
Communicate and monitor
Tell stakeholders when the migration happens, what might be affected and how rollback would be announced. During and after cutover, monitor errors, latency, replication status and data validation checks. Keep the old system intact and reachable until the agreed observation period has passed.
After the migration
Once the new system is stable, decommission the old one deliberately: take a final backup, record where it is stored and remove temporary sync processes. Review what went well and what to change in the next plan.
Key takeaways
- Choose a rollback approach for each step and keep destructive changes for last.
- Test backup restores and know your recovery time.
- Decide how post-cutover writes are handled before you switch.
- Write a runbook, set criteria in advance and rehearse the whole plan.