The Parallel Universe: 30 Days of Identical Output
Estimated read: 2 min
Every reconciliation technique from the last two sections – count parity, hash-diff, the nightly audit table – has been described so far as a way to check a table pair. A parallel run is where that machinery gets pointed at the whole system at once: for a defined window, typically 30 days and at least one full month-end close, Oracle keeps running as the system of record while Databricks ingests, transforms, and reports the exact same data on its own pipelines, in parallel. Every report a business user pulls from Databricks during that window gets compared against the Oracle-sourced equivalent they already trust.
Thirty days is not an arbitrary number. It is chosen to guarantee the parallel run crosses at least one full month-end close – the highest-stakes, highest-complexity workload the legacy warehouse runs, full of period-end accruals, allocations, and adjusting entries that a random Tuesday’s data never exercises. A migration that only reconciles daily operational loads and skips a full close cycle has not actually tested the scenario most likely to surface a translated PL/SQL bug or a rounding mismatch in a re-architected aggregation.
The reconciliation engine built in the previous section is what makes a 30-day parallel run tractable rather than a month of manual spot-checks. The same nightly Lakeflow Job that has been running since day zero of development keeps running through the parallel window, now checking full production volumes instead of a development subset, with its Delta audit table accumulating one row per table pair per night. By the end of the window, that table isn’t just evidence for the migration team – it’s the artifact a business sponsor points to when asked to defend the go-live decision.
Nobody reads a 30-night audit table row by row, so the practical unit of “identical output” is the daily and end-of-close summary: zero open mismatches across every table pair, for every night, with no exceptions waived away as “probably fine.” One unexplained mismatch on night 12 doesn’t necessarily restart the clock, but it does mean the parallel run isn’t finished until someone has traced that mismatch to a root cause and confirmed it won’t recur – a single yellow cell on the dashboard is reason enough to keep the window open past 30 days rather than call it done on the calendar alone.
A parallel run that finds zero mismatches in the first week is not evidence the migration is done – it’s evidence the easy cases pass. The value of the full 30 days is forcing every table pair through a real month-end close, where the legacy system’s edge cases actually fire.
The next lecture walks through what a financial close specifically stresses that day-to-day operational data does not, and why closing the books identically in both systems is the bar that actually matters to the business.
| ← Previous: The Parallel Run and Zero-Downtime Cutover | Next: Running Oracle and Databricks Through a Financial Close → | |:—|—:|