Cutover Patterns: Phased vs Big Bang
Estimated read: 3 min
A clean parallel run answers “does the data match?” It doesn’t answer “how do we move the business over?” That’s a separate decision with its own two dominant patterns, and picking between them is a risk-versus-speed tradeoff, not a technical one.
Big bang cutover moves every workload, every user, and every downstream consumer to Databricks on a single date. Legacy is decommissioned (or frozen read-only) the same weekend the new platform goes live for everything. Phased cutover moves one workload, business unit, or table domain at a time – accounts payable this month, accounts receivable next month, financial reporting last – with legacy and Databricks coexisting, each serving different slices of the business, for the length of the whole rollout.
| Big Bang | Phased | |
|---|---|---|
| Timeline to full legacy decommission | Fastest – one event | Slowest – weeks to months per wave |
| Blast radius of a defect | Entire business, all at once | One workload or business unit at a time |
| Dual-running cost (compute, licenses, ops effort) | Short window, high intensity | Extended window, lower intensity per wave |
| Reconciliation surface per event | Everything, simultaneously | One wave’s tables and workloads |
| Rollback complexity if something breaks | Rolling back the whole business | Rolling back one wave, others unaffected |
| Organizational readiness required | All teams cut over-ready on the same date | Each wave’s team ready on its own schedule |
Big bang’s appeal is that it’s over – no months of running two systems, two sets of grants, two sets of dashboards that might silently drift apart. Its cost is that every defect the parallel run and reconciliation engine missed shows up in production, everywhere, on day one, with no smaller blast radius to contain it.
Phased cutover trades that risk for calendar time. Moving accounts payable in isolation means a defect in the AP translation only affects AP, and the team has a full reconciliation cycle on that one domain before the next wave starts. The cost is real: dual-running two production systems for months means two sets of Unity Catalog grants and Oracle roles staying in sync, two operational runbooks, and the reconciliation engine staying in continuous use far longer than a single 30-day window.
The 3-R decision from earlier in this course (rehost, re-platform, re-architect) and the cutover pattern are independent choices – a re-architected workload with heavy schema changes is often a poor fit for big bang precisely because more changed simultaneously means more that can go wrong at once, while a straightforward rehost of a self-contained data mart is a reasonable big-bang candidate.
In practice, most enterprise migrations land on phased for anything beyond a small, self-contained system, and the next lecture describes the specific three-stage mechanism – read-only, then read-write, then decommission – that makes each individual wave of a phased cutover safe to execute.
| ← Previous: Running Oracle and Databricks Through a Financial Close | Next: The Soft Cutover: Read-Only, Then Read-Write, Then Decommission → | |:—|—:|