Comparison
Big bang migrationvsSchema migration
Big bang migration
everything switched over on one weekend, and the rollback plan was a sentence in a document.
Moving everything from the old system to the new one at a single moment. It is sometimes unavoidable — some data models and some vendors do not allow a gradual path — and it should be recognised as the highest-risk option available, because every problem arrives at once and the rollback window is the same weekend. Where it cannot be avoided, the mitigation is rehearsal: run the cutover against production data more than once before the real one.
Full entry →Schema migration
you have to change the shape of a table that is being read and written right now, without stopping either.
A versioned change to the database structure, applied in order and tracked alongside the code. The hard part is not the DDL but the overlap: old and new application versions run simultaneously during a deploy, so every migration must be compatible with both. A migration that takes a lock on a large table can be indistinguishable from an outage.
Full entry →