Both paths end with the database in a known, tracked state. They differ in what they cost and what they assume. Rolling back restores the previous state using rollback scripts. Fixing forward ships a new corrective changeset through the same pipeline as any other change. This page is the decision, not the procedures. The procedures live in their own guides.

What each path assumes

• Rollback: Assumes your rollback scripts exist and are tested. Automatic rollbacks cover many modeled changes, and SQL changelogs need explicit rollback blocks. Untested rollback scripts are not a recovery plan. They are a second incident.

• Fix forward: Assumes you can diagnose and correct the change quickly enough for the situation. It keeps everything moving through the normal pipeline. Checks run, the operation reports, and the audit trail stays continuous.

Choose by these factors

• Data loss: Rolling back structural changes that carried data, such as restoring a dropped column or reverting a transformed table, can destroy data the forward change created. When data has already moved, fixing forward is usually the only safe answer.

• Scope of the failure: A failed update leaves earlier changesets deployed, so you rarely need to unwind everything. Targeted rollbacks take back a specific changeset rather than the whole run.

• Urgency versus certainty: A tested rollback is fast and predictable, which is what matters when production is degraded and the clock is running. Fixing forward is right when the failure is understood and the fix is small.

• What your team has practiced: The path your pipeline rehearses is the safer path during an incident, whichever it is. Make that choice as a strategy decision before the incident, not during it.

Either way, stay in the pipeline

Roll back with your rollback commands, or deploy the corrective changeset with update. In both cases, use the same governed path as any other change, so policy checks run, the operation reports, and the record shows the incident and its resolution end to end. A manual fix applied directly to the database converts a deployment problem into a drift problem.