Design a rollback plan before you ship a risky migration
A migration plan without a rollback plan is a bet you can't take back.
- Use it for
- Engineers shipping a schema migration, data backfill, or irreversible-looking change.
Most migration plans describe the forward path in detail and treat rollback as an afterthought — "we can always restore from backup" — which is true in the abstract and useless at 2am when a backup restore means hours of downtime and the migration is only half-applied. A real rollback plan is designed alongside the forward migration, not improvised after something breaks, and accounts for the specific ways this migration fails partway.
This prompt forces the rollback design to happen before the migration ships, tied to the migration's actual failure modes, not a generic disaster-recovery boilerplate.
When not to use this
For a migration that's trivially reversible (adding a nullable column) or fully tested against a realistic staging copy with a clear all-or-nothing transaction boundary, this level of ceremony is more than the risk warrants. This is for migrations that touch a lot of data, run over real time, or can't cleanly wrap in one transaction.
Did this work?
You have a specific, tested-on-paper rollback path for the actual failure modes of this migration — not a generic "we'll restore from backup" that would take hours you don't have during an incident.
Tested on claude-opus-5. Evidence status is draft; it moves to battle-tested only on recorded runs, never by hand.