State and recovery
Moving data from one shape to another while the business keeps running — and the risk is never the data, it is the interval where two shapes are both live.
Also called Data migration · Schema change · Миграция
The dangerous property is that a migration is not a moment. Old code and new data, or new code and old data, coexist for as long as the deployment takes, and every migration that has ever caused an incident caused it inside that window. Which is why the safe shape is additive and staged: add the new column, write to both, backfill, read from the new one, and only then remove the old — four deployments, each of which is reversible on its own.
The irreversible steps are the ones to name in advance. Dropping a column, rewriting a value in place, changing a primary key: after these there is no path back except a restore, which converts a routine change into a recovery event with an RPO attached to it.
And a migration that has only been run on an empty database has not been tested. Row counts change the plan, timeouts appear at scale, and a statement that takes a second on a developer machine can hold a lock for minutes on production and stop everything behind it.
The rollback plan is “restore the backup”, which means the plan for a routine change is a recovery event — and it is discovered mid-window, with the business stopped, by somebody who did not expect to be doing it. Stage the change so every step is separately reversible, and rehearse it against a copy with production volumes.
The definitions are the easy part. Whether the figure on your dashboard was computed this way is a different question, and usually the more expensive one.