Extract, land and load

Extract, land and load moves data through files in a controlled landing area:

Source database
  → bounded, restartable extracts
    → Object Storage landing zone
      → external tables or governed loading interfaces
        → validated target tables

It is the right approach for non-Oracle sources, and for any migration that includes substantial transformation, consolidation, data repair or a new target model. Its real advantage is that the files and their manifests form an explicit contract between extraction and loading, which makes the whole process checkable and restartable — a property the other methods do not give you.

Make extraction restartable, not fast

Divide the source into fixed partitions or ranges that can be extracted and loaded independently. Never run a single export whose scope can change while it is running; you cannot validate it, and if it fails at 80% you start again.

Each unit gets a stable identifier, a versioned schema contract and a manifest. Once produced, a unit is immutable. After a failure, the manifest tells you exactly which units are complete, which can be resumed and which can be safely reloaded. The portable pipeline specification in the reference section lists what the manifest needs to carry.

Define type conversions, character set handling, timestamp semantics, null treatment, rejected-row handling and reconciliation before implementation. These decisions get made either way; the only question is whether they are made deliberately by an architect or accidentally by whoever wrote the loader.

Formats and the second-platform trap

Parquet is worth choosing when tools outside the database need efficient columnar access to the same data. Apache Iceberg adds table management for data held in object storage and suits a governed lakehouse layer.

Both are legitimate target choices. But for every file-based data set you propose, record who will use it, who will manage its security and quality, and how long it is kept. A landing zone that acquires consumers becomes an unplanned second platform with no owner and no lifecycle — and you will not notice until someone builds a report on it.

Capturing the final changes

Three options: a fixed read-only period, extraction from a watermark, or change data capture assessed separately. Whichever you choose, rehearsal has to prove it produces a consistent result and can recover from failure. This is the part of extract-land-load that teams design last and should design first.