The Parallel Run and Zero-Downtime Cutover

Everything built in the last two sections – the reconciliation stack, the hash-diff engine, the nightly audit table – exists to answer one question the business will ask on cutover day: how do you know this is safe? This section is where that evidence gets turned into a decision. A parallel run proves the new platform produces identical output against a real financial close, a cutover pattern decides how much of the business moves at once, and a trust gate turns a green dashboard into a signed-off go/no-go that a business owner, not an engineer, is accountable for. The section closes with the two things that turn “we’re confident” into “we’re covered” if something still goes wrong: a rehearsed rollback and a tested backfill path back into the system being retired.

flowchart LR
    A["Parallel run\n30 days, both systems live\nOracle = system of record"] --> B{"Reconciliation\nclean for N\nconsecutive closes?"}
    B -- no --> A
    B -- yes --> C["Trust gate\nsign-off table\nall gates approved?"]
    C -- no --> A
    C -- yes --> D["Soft cutover\nread-only"]
    D --> E["Soft cutover\nread-write\nDatabricks = system of record"]
    E --> F{"Rollback\nneeded?"}
    F -- yes --> G["Merge backfill\ninto Oracle\nfrom rehearsed clone"]
    F -- no --> H["Decommission\nlegacy system"]

Lectures

#	Lecture	Est. Read
1	The Parallel Universe: 30 Days of Identical Output	2 min read
2	Running Oracle and Databricks Through a Financial Close	3 min read
3	Cutover Patterns: Phased vs Big Bang	3 min read
4	The Soft Cutover: Read-Only, Then Read-Write, Then Decommission	3 min read
5	Business-User Sign-Off and the Trust Gate	3 min read
6	Backfill and Rollback Pre-Testing	3 min read
7	Check Your Knowledge	Quiz

| ← Previous: Check Your Knowledge | Next: The Parallel Universe: 30 Days of Identical Output → | |:—|—:|

The Parallel Run and Zero-Downtime Cutover

Lectures

Table of contents