Comparison
Roll forwardvsRollback
Roll forward
you cannot go back because the migration already ran, so the only way out is to ship another change quickly.
Fixing a bad release by deploying a newer version rather than reverting. It is necessary when a rollback would be destructive — irreversible migrations, consumed messages, already-published events. It is riskier under incident conditions, so it should be a consequence of the change's shape, not a habit.
Full entry →Rollback
the deploy broke something so you put the previous version back rather than trying to fix forward under pressure.
Returning to the previously known-good version. It is the correct default response to a bad deploy, and its speed is a top-tier reliability metric. It is only available if every change is backward compatible with the previous version's data — an unrecoverable migration makes rollback impossible exactly when you need it.
Full entry →