Waves or big bang
The most consequential project-shape decision, usually made by default rather than deliberately.
This is the most consequential project-shape decision, and it is usually made by default rather than deliberately.
Big bang means one cutover: the whole platform moves, everything re-points, the source is frozen. It is operationally simpler, there is one window to negotiate, one reconciliation exercise, one rollback boundary, and no period during which two platforms must be kept consistent. It is also unforgiving. If validation finds a problem at hour thirty of a thirty-six hour window, your options are narrow.
Waves means migrating in groups, with the source and target both live and serving different consumers for a period. It de-risks each individual cutover, lets the team learn from wave one before wave four, and spreads the business disruption. What it buys in risk it pays for in complexity: for the duration, you are running two platforms, keeping them consistent, and answering the question “which one is right?” every time a number differs.
Note that rolling catch-up is a third shape and often the best one: the platform moves progressively over weeks and the cutover handles only the residual gap.
The architecture decides this more than the risk appetite does, which is why the archetypes come first. An organically grown, line-of-business estate decomposes naturally and waves are the obvious shape. An architected medallion platform resists decomposition by design, and waves attempted across its layers create cross-platform dependencies in the most heavily used part of the estate.
So the rule I work to is: waves where the platform decomposes; otherwise big bang or rebuild, unless you can restructure the problem so that it decomposes. That last clause is the interesting one, and the next section is how I have done it.
Where waves are on the table, three conditions have to hold:
- The platform decomposes along consumer lines, so a wave moves a data domain and its consumers together with no residual cross-dependency.
- The available outage window genuinely cannot accommodate the whole platform, and no method closes the gap.
- The business will not accept the blast radius of a single cutover, and has said so at a level that owns the consequence.
The failure mode to avoid is waves defined by table groupings rather than consumer groupings. If wave one moves the tables but wave three moves the reports that read them, you have not reduced risk — you have created a cross-platform dependency and guaranteed a coexistence period you did not plan for.
Define waves by consumer, not by data. A wave is done when a group of users is served entirely by the new platform, with nothing left pointing back.
