The Soft Cutover: Read-Only, Then Read-Write, Then Decommission
Estimated read: 3 min
A “cutover” sounds like a single switch flip: one moment legacy is the system of record, the next moment Databricks is. In practice, flipping every consumer’s read and write path at once is exactly the single point of failure a phased approach is trying to avoid. The soft cutover breaks that one event into three distinct, individually reversible stages, each of which can be paused or backed out of without touching the next one.
flowchart LR
S1["Stage 1: Read-Only\nUsers read from Databricks\nOracle stays system of record\nfor writes"] --> S2["Stage 2: Read-Write\nDatabricks becomes\nsystem of record\nOracle mirrors via CDC"]
S2 --> S3["Stage 3: Decommission\nOracle frozen / archived\nDatabricks is sole\nsystem of record"]
Stage 1 – read-only. Business users and downstream reports get pointed at Databricks for reads, while every write – new orders, journal entries, updates – still lands in Oracle first, same as before the migration ever started. This is the lowest-risk stage in the whole cutover because there is no new write path to get wrong: Databricks is simply an additional read surface, running behind CDC or the same batch pipelines used during the parallel run, and if anything looks wrong, users are switched back to Oracle reports with zero data at risk since nothing new was ever written to Databricks.
Stage 2 – read-write. Databricks becomes the system of record for writes. New transactions land in Databricks first; Oracle either stops receiving new writes entirely or is kept as a mirror via the same CDC and Lakeflow Declarative Pipelines machinery used earlier in this course, now running in the reverse direction from what a straightforward migration would suggest – Databricks to Oracle instead of Oracle to Databricks. This is the highest-risk stage, because a bug here means a business transaction that never makes it anywhere durable, not just a stale report. It’s also why stages 1 and 2 are never combined: proving the read path works first, in isolation, removes one whole category of variable before the write path is trusted with anything real.
Stage 3 – decommission. Once read-write has run cleanly for an agreed period – itself validated by the reconciliation engine, which keeps running through every stage, not just the parallel run window – Oracle is frozen to read-only for audit and compliance retention, or archived outright, and Databricks is the sole system of record. This is the only stage that is genuinely hard to reverse, which is exactly why it happens last and only after the previous two have already built a track record.
The three stages are not a formality to move through quickly – each one should run long enough to build real evidence (a full reconciliation cycle, ideally a full close) before advancing to the next. Collapsing stage 1 and stage 2 into a single event reintroduces the big-bang risk profile the phased pattern exists to avoid.
Note that “soft cutover” describes one wave of a phased migration, not the whole migration at once – a large program runs this same three-stage sequence independently for accounts payable, then again for accounts receivable, then again for financial reporting, each wave on its own calendar, rather than trying to march every workload through all three stages in lockstep. That independence is what lets one wave’s stage-2 defect stay contained to that wave instead of stalling every other team’s progress.
The soft cutover gives engineers confidence the write path works. It doesn’t by itself give the business permission to treat that confidence as a decision – that’s a separate, explicit gate, covered next.
| ← Previous: Cutover Patterns: Phased vs Big Bang | Next: Business-User Sign-Off and the Trust Gate → | |:—|—:|