The 72-Hour Rollback Window
Estimated read: 3 min
Earlier in this part, the parallel-run section covered how to rehearse a rollback – shallow and deep clones, an idempotent MERGE INTO backfill, a reconciliation check to confirm the rollback landed clean. This lecture covers the piece the runbook has to formalize on top of that mechanism: a fixed rollback window, agreed by the steering committee before cutover, that states exactly how long the legacy system stays warm and reachable after Databricks becomes system of record.
Seventy-two hours is the number most legacy-to-Databricks cutovers converge on, and it’s not arbitrary – it’s long enough to cover one full business cycle plus a buffer. A single day only proves a system survived one nightly batch and one morning of user traffic; problems that show up on a month-end close, a weekly batch job, or a report a business user only runs on a specific day of the week won’t surface in 24 hours. Three days covers at least one full business-day cycle with margin for a second look before the legacy system’s plug actually gets pulled. A window shorter than that trades safety for a faster decommission; a window much longer than that starts costing real money and calendar time keeping a system nobody’s using warm, licensed, and staffed.
The window isn’t a single 72-hour countdown with no checkpoints – it has structure:
| Checkpoint | What’s verified |
|---|---|
| T+0 (cutover) | Databricks becomes system of record; Oracle switches to read-only warm standby, not decommissioned |
| T+24 | First full daily batch cycle on Databricks reconciles clean; smoke tests across critical reports pass |
| T+48 | A second daily cycle reconciles clean; any T+24 issues are resolved, not just noted |
| T+72 | Steering committee reviews the full window’s reconciliation history and makes the go/no-go call: proceed to decommission, or execute the rollback |
“Warm standby” means Oracle keeps ingesting nothing, stays untouched, and is capable of resuming as system of record within the backfill procedure’s tested recovery time – it does not mean “we still have the VM.” A legacy system that’s been left running but unverified since cutover is not actually a rollback option; it’s an assumption that hasn’t been tested since the window opened.
If T+72 arrives and every checkpoint reconciled clean, the steering committee approves moving to decommission – and the legacy system’s warm-standby period ends on a decision, not by default. If any checkpoint didn’t hold, the backfill-and-rollback procedure from earlier in this part executes against the still-warm Oracle instance, and the cutover clock resets. Either way, the decision gets made deliberately, by the people the steering committee lecture put in the room to make it – which is exactly what the section’s closing quiz checks understanding of next.
| ← Previous: Stakeholder Communication and the Steering Committee | Next: Check Your Knowledge → | |:—|—:|