Assume It Can Fail
Any migration can go wrong after release, so a plan to reverse course is part of the design, not an afterthought. Good rollback planning decides in advance how to get back to a known good state without losing data.
Reversible By Design
- Prefer additive changes first: adding a column is easy to undo, dropping one is not.
- Keep the old path working until the new one is proven, so reverting is just a redeploy.
- Avoid destructive steps like dropping columns until well after cutover succeeds.
A migration built from additive backward compatible steps can usually roll back by simply deploying the previous application version.
When Forward Only Is Safer
Some changes cannot be cleanly reversed once new data has been written in the new shape. Here teams plan a roll forward fix instead: a follow up migration that corrects the problem, because reverting would lose data created after the change. Either way, the team defines a decision point and a time budget: if validation or error rates breach a threshold, the rollback or roll forward is triggered without debate.
Key idea
Rollback planning favors additive reversible steps with a known good fallback, and where reversal would lose data it plans a roll forward fix, all triggered by predefined thresholds.