Big bang vs. phased migration: how to actually choose

Early in almost every migration, someone asks the question that shapes the whole plan: do we move everything at once – a big bang cutover – or do we migrate in phases? It gets debated hard, often by people defending a preference rather than weighing the trade. And the honest answer is that neither is "best": they trade different risks, and the right choice falls out of your constraints, not a rule of thumb.

Here's how I think it through with a client.

What each approach actually means

Big bang. You pick a cutover window – usually a weekend or a holiday – freeze the old system, migrate everything, validate, and bring everyone up on the new system at once. One moment, one switch.

Phased. You break the move into stages and cut over a piece at a time: by business unit, by geography, by module (finance first, then logistics), or by data domain. Between stages, the old and new systems coexist, and you run them together for a while.

That coexistence is the crux of the whole decision, so hold onto it.

Big bang: the case for and against

For it:

• No coexistence to engineer. You don't have to keep two systems synchronised, because there's only ever one system of record at a time. This is a bigger saving than it sounds – the integrations that keep old and new agreeing during a phased move are often the hardest part of the whole programme.
• It's quicker to "done". One push, one cutover, and the legacy system is off. No drawn-out period of running two worlds.
• It's conceptually clean. Everyone changes on the same day; there's no confusing in-between state where some data lives here and some lives there.

Against it:

• Concentrated risk. Everything rides on one window. If something goes wrong at 3am on cutover Sunday, you're making a go/no-go call under maximum pressure with the whole business waiting.
• Rollback is brutal. Backing out a big bang means reverting everything and explaining a missed go-live. The later you discover the problem, the worse the position.
• It demands readiness you have to prove in advance. The data has to be right before the window, because there's no second stage to catch what slipped. That's a high bar – and meeting it is exactly what mock runs and reconciliation are for.

Phased: the case for and against

For it:

• Contained blast radius. If stage one (say, one country or one division) has problems, it affects that slice, not the entire enterprise. You learn on a small population and carry the lessons into the next stage.
• Rollback is realistic. Backing out one stage is a far smaller event than backing out everything. The decision is less terrifying, so it gets made on its merits.
• The team builds a rhythm. By the third cutover, the runbook is sharp and the surprises are mostly behind you.

Against it:

• Coexistence is expensive and hard. While you're half-migrated, the old and new systems both hold live data and must be kept in step – which means temporary integrations, reconciliation between the two, and rules for which system owns what. This is real engineering, and it's throwaway: you build it only to tear it down.
• It takes longer, and dual-running costs the whole time. You carry two platforms, two sets of support, and the cognitive load of an in-between world for months.
• Splitting the data is sometimes genuinely hard. Shared master data, intercompany transactions, group-level reporting – some things don't cut cleanly along a business-unit or module line, and forcing the split creates its own problems.

The factors that should actually decide it

Strip away the preferences and the decision comes down to a handful of real constraints:

• Downtime tolerance. Can the business actually go dark for a weekend? A 24/7 operation – manufacturing, logistics, healthcare – may have no window big enough for a big bang, which pushes you toward phasing whether you like it or not.
• Rollback appetite. How catastrophic is a failed cutover? The less the business can absorb a bad go-live, the more a phased approach earns its overhead by shrinking each individual bet.
• How separable the data is. If your business units, regions or modules are genuinely loosely coupled, phasing is natural. If everything shares master data and intercompany flows, a clean split may cost more than it saves.
• Scale and complexity. A handful of systems and a contained dataset can be moved in one careful window. A sprawling, high-volume, many-source landscape concentrates too much risk into one night.
• The cost and feasibility of coexistence. Phasing is only as good as your ability to keep the two worlds in step. If temporary integration is cheap and reliable, phasing is attractive; if it's a nightmare, that argues for the single clean cut.
• Calendar constraints. Year-end, regulatory deadlines, peak trading seasons – these can rule a window in or out regardless of everything else.

The honest middle ground

In practice the choice is rarely purely one or the other. Common, sensible hybrids:

• Big bang per business unit. Each division does its own single cutover, but the divisions go live on different dates – contained risk without the full cost of data-level coexistence.
• Phase the history, big-bang the operations. Cut everyone over to the new system at once for live, open transactions, and bring historical data across in a later, lower-stakes phase (or leave it queryable in the legacy system).
• A pilot, then a big bang. Migrate one small, friendly unit first as a true rehearsal on real data, learn from it, then move the rest together with the runbook proven.

How to decide, concretely

Don't argue it in the abstract. Make the constraints explicit and let them choose:

1. Write down the downtime the business can truly tolerate – not the optimistic number, the real one.
2. Decide how bad a failed cutover is, in plain business terms, and therefore how much rollback safety is worth paying for.
3. Test whether the data separates cleanly along the line you'd phase on – shared masters and intercompany flows are where this breaks.
4. Price the coexistence a phased move would require, honestly, including the throwaway integration work.
5. Then choose – and whichever you pick, the things that actually de-risk it are the same: profiling, cleansing with clear ownership, multiple mock runs, and real reconciliation. The cutover strategy decides how the risk is shaped; the disciplined data work decides whether you succeed.

There's no universally right answer here, and anyone who gives you one without asking about your downtime tolerance and your data hasn't understood the question. Choose deliberately, for reasons you can defend to a steering committee.

Weighing big bang against a phased rollout for your migration? Get in touch – I'm happy to talk it through.

---

Related reading: Why data migrations fail.