When a deployment causes harm, recovery needs a known path back to acceptable behavior.

A rollback restores an earlier application version or configuration. It is effective when the previous version is still compatible with the current external state.

That condition can fail. A new release may have written data in a representation the old release cannot read, sent irreversible external side effects or applied a destructive schema change.

Forward recovery instead deploys another change that repairs the problem while preserving the newer state. It is often safer when undoing state is ambiguous or destructive.

Recovery planning should therefore happen before deployment: identify reversible changes, preserve old compatibility where rollback is expected, and know which effects require a compensating or forward fix.

“Can we deploy this?” and “can we recover from this deployment?” are separate engineering questions.