Sequencing: What Order, What Parallel, What Blocks What

Estimated read: 3 min

A runbook lists steps; a sequence decides which of them can run at the same time. Get this wrong in one direction and the migration takes twice as long as it needs to, with engineers idle while a single conversion step finishes. Get it wrong in the other direction and two workstreams collide – someone starts reconciling a table whose schema hasn’t been frozen yet, and every number they produce is invalid the moment the schema changes underneath them.

The starting point for sequencing is a dependency graph, not a Gantt chart. A Gantt chart shows when things are planned to happen; a dependency graph shows why they have to happen in that order, which is what actually lets the team compress the schedule safely. The graph’s root node, for almost every legacy warehouse migration, is schema freeze: the point where the source system’s DDL for a given domain stops changing. Nothing downstream – DDL translation, code conversion, reconciliation logic – can be trusted until the schema it’s built against is fixed, because a column added to the Oracle source after translation has already run is a silent, invisible gap in the target schema.

From schema freeze, the graph has both hard blocks and parallel tracks:

Logic conversion is a hard block. PL/SQL-to-PySpark transpilation for a given domain has to complete and pass code review before reconciliation for that domain can start, because reconciliation is checking the output of that converted logic – there’s nothing to reconcile against until it exists.
Ingestion and reconciliation parallelize per table. Once conversion for a domain is done, there’s no dependency between reconciling the orders table and reconciling the customers table – they can run concurrently, each with its own hash-diff check, each on its own timeline. This is where most of a migration’s calendar time gets clawed back: instead of one linear queue of 340 tables, a dozen tables move through ingestion and reconciliation at once.

Schema Freeze
  -> Logic Conversion (hard block, per domain)
       -> Reconciliation: orders     ┐
       -> Reconciliation: customers  ├─ parallel, per table
       -> Reconciliation: inventory  ┘
            -> Parallel Run (domain-level, once all tables reconcile clean)

A hard block that gets treated as parallelizable is the single most common source of a migration having to be re-run from scratch – reconciling against logic that later gets revised invalidates every number produced in the meantime, and nobody finds out until the steering committee asks why two reconciliation reports for the same table disagree.

Every edge in this graph is also a place a risk can materialize – a conversion that takes three times longer than estimated, a table whose reconciliation never goes clean – which is exactly what the next lecture’s risk register exists to track against the graph, not as a separate document but as an overlay on it.

| ← Previous: The End-to-End Migration Runbook | Next: The Risk Register: Naming Every Way It Can Fail → | |:—|—:|