Running Oracle and Databricks Through a Financial Close

Estimated read: 3 min

A financial close is the one workload every legacy warehouse team already respects as unforgiving: a fixed calendar window, a strict sequence of dependent jobs (subledgers close before the general ledger consolidates, allocations run before the trial balance is pulled), and a finance team waiting on the other end who will notice a number that’s off by a rounding error. Running that exact sequence through Databricks during the parallel run window is the closest thing to a full production drill the migration gets before cutover.

The first friction point is timing dependencies. A legacy ETL close job typically encodes its sequencing as an implicit contract – job B starts at 2 a.m. because job A, which it depends on, has always finished by 1:45 a.m. Lakeflow Jobs makes that dependency explicit instead of assumed: each close step becomes a task with declared upstream dependencies in a DAG, so the accruals task literally cannot start before the subledger task succeeds, regardless of how long either one takes on a given night. See the Lakeflow Jobs documentation for how task dependencies, retries, and run history work. This is stricter than most legacy schedulers, and it routinely surfaces a close-sequencing assumption nobody had written down.

The second is period-end adjustments – manual journal entries, currency revaluations, and allocation runs that don’t touch the system on a normal day but dominate close week. These are exactly the code paths most likely to still be running as untranslated PL/SQL procedures or manual spreadsheet macros feeding into Oracle, because they’re low-frequency and easy to defer during migration. A parallel run forces them to be migrated and reconciled before the close window closes, not after.

-- Reconciling a specific close-week output: trial balance by cost center
SELECT
  cost_center,
  SUM(debit_amount)  AS total_debits,
  SUM(credit_amount) AS total_credits
FROM gold.finance.trial_balance
WHERE close_period = '2026-07'
GROUP BY cost_center
ORDER BY cost_center;
-- Compared row-for-row against the equivalent Oracle GL query via the
-- hash-diff engine, not eyeballed against a spreadsheet export.

Treat the financial close as the parallel run’s real acceptance test, not a bonus check. A migration that reconciles cleanly on ordinary operational days but has never run a full close through Databricks has not yet tested the workload the business will actually judge it by.

A clean close reconciliation is strong evidence, but it only proves the data matches – the next lecture turns to the separate question of how the business actually moves its users and workloads over, which is a sequencing decision independent of whether the numbers already tie out.

---

| ← Previous: The Parallel Universe: 30 Days of Identical Output | Next: Cutover Patterns: Phased vs Big Bang → | |:—|—:|