Two ways to make the switch
Every migration eventually needs a cutover: the point at which users stop relying on the old system and start using the new one. The two broad patterns are a “big bang”, where everyone and everything moves at once, and a phased approach, where the move happens in stages. Many real projects land somewhere in between, so treat these as ends of a spectrum rather than a strict choice.
Choosing a cutover strategy is a risk decision more than a technical one. Neither option is inherently better.
What a big bang cutover looks like
In a big bang, a single date is set. Data is loaded, the old system is switched off or made read-only, and the new system becomes the only place to work. This often happens over a weekend or another quiet period.
Where it tends to help
- There is one transition to manage, rather than a long period of mixed working.
- No temporary connections between old and new systems need to be built.
- Everyone works the same way from the same date, which can simplify training and support.
- The total project timeline can be shorter.
Where it tends to hurt
- All the risk lands on one moment. If something fails, it fails for everyone.
- Testing has to be thorough, because there is little chance to learn gradually.
- Support teams face a surge of questions at once.
- Rolling back is harder once new transactions have been recorded, so a rollback plan has to be decided before the date, not during it.
What a phased cutover looks like
A phased cutover moves in slices. The slices might be by site, business unit, product line, country, customer group or function. A small pilot group might go first, then others follow in waves.
Where it tends to help
- Problems show up with a small group, where they are cheaper to fix.
- The team can apply lessons from earlier waves to later ones.
- Support demand is spread out.
- The business can keep operating if one wave is delayed.
Where it tends to hurt
- The old and new systems coexist for a period, so data and reports may need to span both.
- Temporary interfaces must be built and later thrown away, which adds effort and its own bugs.
- The project runs longer, which can mean fatigue, cost and drift in staff attention.
- People in the old system can feel left behind, while those in the new one may work with partial information.
- Some processes cannot easily be split, for example a single ledger or a shared customer record.
Comparing the risk profiles
| Factor | Big bang | Phased |
|---|---|---|
| Number of transitions | One | Several |
| Impact if it goes wrong | Broad, immediate | Limited to the current wave |
| Temporary interfaces | Few | Usually more |
| Duration of mixed working | Short | Longer |
| Learning between stages | Little | Considerable |
| Ease of rollback | Often harder after go-live | Easier within a wave |
The table is a generalization. A well-rehearsed big bang can be less risky than a poorly controlled phased rollout, and a tidy phased plan can still be undermined by hidden dependencies.
Questions that help decide
- How separable are the processes? If sites or units work independently, phasing is easier. If they share data in real time, splitting them may be difficult.
- How much can the business tolerate? A business that cannot accept any disruption in a given period may prefer small steps. A business with a clear quiet window may be comfortable with one switch.
- How strong is the testing? Thorough rehearsals of data loads and cutover steps make a single switch more credible.
- How much support capacity exists? A single day of heavy demand may exceed the help desk, while a staged rollout can match capacity.
- What does the old system’s end of life look like? A fixed contract end or support expiry may force the timeline.
- Is there a way back? If returning to the old system is realistic, risk is lower for either approach.
Hybrid patterns
Several variations sit between the extremes:
- Pilot then big bang. One small group uses the new system first, then everyone else moves together.
- Phased by function. Back-office modules move one at a time, but each module moves for all users at once.
- Parallel running. Both systems are used side by side for a set period. This reduces some risks but doubles some work, and it is explored in the parallel running article in this cluster.
Common mistakes
- Choosing a strategy because it sounds modern or because a supplier recommended it, without checking it against the organization’s own dependencies.
- Underestimating the temporary work in a phased plan.
- Treating the cutover date as fixed even when readiness criteria have not been met.
- Skipping a rehearsal of the actual cutover steps, with timings.
- Forgetting the people side. Even a technically smooth cutover can cause disruption if staff are not prepared, which is where organizational change management and system training approaches matter.
A sensible approach is to write down the main failure scenarios for each option, estimate how bad each would be, and ask which the organization is better prepared to handle. Outcomes remain uncertain either way, which is why go/no-go criteria and a tested fallback are worth agreeing early.