Choose by where the risk sits and by whether you can stop. A big bang puts all the risk into one cutover and pays nothing until it lands. A phased rollout spreads the risk across steps and pays for two systems in the meantime. This guide gives the conditions that point to each, a safe order for phasing and the rules that hold either way.
What a big bang costs
A big bang moves every user, record and interface on one day. Some replacements are small enough for that. Three costs come with it.
- No value until the last day. Nobody uses the new system before cutover, so nobody can tell you that it is wrong while correcting it is cheap.
- A target that drifts. The business keeps trading through a long build. Each change is made in the old system so work continues, then repeated in the new one so the two still match.
- A narrow way back. Reverting has to be decided within hours. After that the only road is forward, with real customers waiting.
The public case people cite is TSB's 2018 migration in the UK. TSB's own account says the main migration event took place in April 2018, moved the core banking data of all five million customers and followed nine dress rehearsals. The board commissioned Slaughter and May to review it, and the report came out on 19 November 2019. The board disputes parts of the findings and points to two data centres set up differently from each other. See TSB's statement on the review. The dispute carries its own lesson. A rehearsal proves the steps you rehearsed, and a single event leaves little room to learn from the rest.
What a phased rollout costs
Phasing has costs too, and plans tend to leave them out.
- Two systems plus a bridge. Both stay in service for the whole programme, with engineers assigned to the link between them.
- A longer planned calendar. Phasing usually shows more elapsed time in the plan than a single cutover does.
- Standing reconciliation. Someone compares the two sets of books for as long as both hold live records.
- A bridge that outstays its purpose. A stop-gap integration that nobody is paid to retire turns into a third system.
The return is resilience. A new sponsor, a frozen budget or a bad quarter leaves you with modules that already work. Each one that moves takes a block of risk off the table.
How to choose
| Condition | Points to |
|---|---|
| The replacement is a few weeks of work | Big bang |
| The two systems cannot share live records | Big bang |
| A fixed outside date, such as end of support or a licence expiry | Big bang, with a rehearsed fallback |
| The business cannot stop trading | Phased |
| Some behaviour exists only in the code | Phased |
| Several sites or business units | Phased |
| The sponsor or the budget is uncertain | Phased |
When both columns apply, split the programme. Move the small, tightly coupled core in one event and phase the surrounding modules.
A safe order for phasing
Move reports first, then a contained workflow, then a module that holds its own records, and the core last. Put every moved capability behind an interface that does not reveal which system is answering, so each step can be reversed. Legacy modernisation without a big bang gives the full sequence and the parallel-run rules.
Rules that hold either way
- Rehearse the cutover and agree abort criteria before the weekend. A rollback plan written at midnight is improvisation.
- Run both systems side by side wherever the ledger is touched. Compare every record by script, not a sample of twenty.
- Write down each difference and its cause. Every one points to a rule nobody documented, and the list becomes the missing specification. Recovering undocumented business rules describes how.
- Fix an exit condition per phase at the start, and treat taking down the bridge as phase work. Without one, the old system survives for years as insurance that you keep paying for.
- Clean the data first. Why ERP data migrations go wrong lists the faults to look for.
How long to run in parallel
Match the period to the cycle that matters. A module that posts to the ledger needs a whole month-end close. A module that feeds quarterly filings needs a full quarter. End the parallel run when every difference has an explanation, not on a date.
Signs a phased plan hides a big bang
A plan can say "phased" and still depend on one night. Look for these signs:
- Every module goes live on the same date, whatever the phase labels say.
- The interface layer is listed as a later task, so nothing can be switched back.
- The old system is switched off on the date the last phase ends, with no read-only period.
- Reconciliation is planned only for the final weekend.
If two of these appear, split the plan again or add a rehearsal and an abort rule for each step.
What to agree before cutover day
Write these down while nobody is under pressure:
- The exact point at which the team will abort, stated as a measurable condition.
- The person who may call the abort, and who is the stand-in.
- The list of interfaces that must answer correctly before users log in.
- The reconciliation reports that must show zero unexplained differences.
- The date the old system becomes read-only, and the date it is switched off.
- The support rota for the first fortnight, with names.
Each item takes minutes to write and removes an argument from the night itself.
The stop test
Suppose the programme halts at sixty per cent because of a new sponsor, a freeze or a merger. What does the company hold? If it holds working modules it can keep, the sequence is sound. If it holds nothing, the plan bets everything on one event and pays off only when a year passes without incident. To rank which system goes first, see choosing the first legacy system to modernise.
Questions teams ask
Does phasing remove the risk?
Safer per step, and dearer overall, because two systems run together. Pick it when the option to stop and keep what you have outweighs the cost of the bridge.
When does a big bang make sense?
When the whole job is small, when the two systems cannot coexist, or when a hard deadline removes the choice. Rehearse it and fix the abort point beforehand.
Why do phased programmes fail?
Usually because the bridge never gets removed. Decide who removes it, and when, before the phase begins.
How do we plan the calendar for either style?
Work from the modules and their dependencies. Custom ERP timeline by phase shows how the stages of an ERP programme line up.
Where Brihat fits
Brihat Infotech's legacy modernisation service plans migration with a strangler pattern and checksummed parallel runs. Start a conversation.