The choice is usually framed as risk against speed: a big bang is fast and dangerous, a phased rollout is slow and safe. That framing is wrong in both directions, and it leads teams to the wrong answer in the cases where it matters.
The real question is where the risk sits, and whether the project can be stopped.
What a big bang actually costs
A single cutover concentrates all risk into one weekend. That is not automatically wrong — plenty of replacements are genuinely small enough — but the properties that come with it are worth naming.
- Nothing ships until everything ships. Value arrives only at cutover, so there is no way to be partially right and no way for a steering committee to course-correct against something nobody has used.
- The target keeps moving. The business does not pause during a long build. Every change has to be made twice — in the old system to keep trading, in the new one to keep parity — and the gap widens.
- The rollback window is hours. If the decision to revert is not made inside it, the organisation is committed to fixing forward under load.
The publicly documented failures are instructive because the shape repeats. When TSB Bank migrated 5.2 million customer accounts in a single event in April 2018, the widely reported consequences — customers locked out for weeks, remediation costs in the hundreds of millions — did not come from a team that could not write software. They came from a migration with no incremental path and no way back.
What a phased rollout actually costs
Honesty in the other direction: phasing is not free, and its costs are the ones people forget to plan for.
- Two systems, plus the bridge between them, maintained for the duration. A real, ongoing engineering load.
- Longer calendar time than a big bang is planned to take — though usually shorter than a big bang actually takes.
- Reconciliation as a standing activity for as long as both systems hold live data.
- A discipline problem: the temporary bridge becomes permanent unless somebody is funded to remove it.
What it buys is optionality. Each capability moved is value delivered and risk retired, and the programme survives a change of sponsor, a budget cut or a bad quarter with something to show.
Choosing
| Condition | Points to |
|---|---|
| Replacement measurable in weeks | Big bang |
| Old and new cannot coexist on the same records | Big bang |
| Hard external date — licence expiry, end of support, deadline | Big bang, with contingency |
| System cannot stop trading | Phased |
| Behaviour exists in code but not in documentation | Phased |
| Multiple sites or business units | Phased |
| Sponsor or budget uncertainty | Phased |
Sequencing a phased rollout
Order matters more than pace:
- Reporting first. Reads are safe. It proves the data model, delivers visible value in weeks, and touches nothing that can corrupt a ledger.
- A bounded workflow with a checkable input and output.
- A module that owns its data. The first genuinely hard step, because it decides where the record of truth now lives.
- The core, by which point most of the surface area has moved and the remaining risk is understood rather than assumed.
Every capability that moves goes behind an interface that hides which system is serving it. That indirection is what makes each step reversible — and reversibility is what turns a bet into a sequence of decisions.
Rules that apply either way
- Rehearse the cutover before the weekend it happens, with abort criteria agreed in advance. A rollback plan written on the night is not a plan.
- Parallel-run anything touching the ledger, reconciling every record automatically rather than sampling twenty.
- Write down every discrepancy and its explanation. Each one is a rule nobody had documented, and the log becomes the specification you never had.
- Decide decommissioning criteria per phase, at the start. Otherwise the old system stays alive for years "just in case" and you pay for both.
The test that settles most arguments
Ask what happens if the programme is stopped at sixty per cent — a change of leadership, a budget freeze, a merger. If the answer is that the organisation has working improvements it can keep, the sequencing is right. If the answer is that it has nothing, the plan has concentrated risk in a way that only pays off if nothing goes wrong for a year.