Skip to content
mcorucu docs
AutoCore1.0.0-rc.1 · Release Candidate
1.0.0-rc.1 · Release Candidate1 min read

Rollback Planning

Decide between roll-forward, application rollback, and database restore before changing an AutoCore release.

Rollback planning considers migration compatibility, data written after upgrade, external-provider side effects, media changes, and legal/payment state. Application rollback is not automatically database rollback.

Prefer roll-forward or idempotent retry when the target schema remains compatible and the failure is operational. Use application-image rollback for stateless service defects only after compatibility review. Consider database restore only when the backup is verified and the data-loss boundary is explicitly accepted.

Destructive gate

A database restore can discard newer data. Obtain explicit approval and preserve the current state before restoring.

Verification

Record the selected path, schema compatibility, data-loss boundary, external side effects, and approval evidence.

Related articles

Application Image RollbackRoll back immutable application images without implying database migration reversal.Database Restore DecisionDecide whether a verified PostgreSQL restore is safer than retry, roll-forward, or image rollback.Recovery Decision MatrixChoose retry, roll-forward, image rollback, or database restore using source-verified AutoCore conditions.