Rollback plan

A rollback plan is a short, written answer, prepared before a release, to the question "how do we undo this if it goes wrong?". It turns a rollback from an improvised fix under pressure into steps someone has already thought through.

What it is

A useful plan covers:

• The trigger: which signal means roll back, such as an error rate, a failed health check or a customer report.
• Who decides: the person on call, without needing a meeting.
• The steps: redeploy the previous build, turn off a feature flag, or move traffic back from a canary.
• Data: whether a migration can be reversed, and what happens to data written by the new version in the meantime.
• How to confirm: the check that shows the old behaviour is back.

The hard part is usually data. A migration that drops or rewrites a column can't be undone by redeploying old code, which is why teams make schema changes backward compatible first and clean up later.

Why it matters

The worst time to work out how to undo a change is during the incident it caused. Writing the plan also surfaces changes that can't be rolled back at all, so they get more review before they ship.

In AI CodeOps

AI CodeOps doesn't store rollback plans. After you roll back in your pipeline, Mark rolled back on the deployment records it: the deployment's status becomes rolled back, and it counts in the change failure rate on the dashboard. Nothing is redeployed by AI CodeOps.