A first conversion, end to end.
This walkthrough drives a single Oracle schema from extraction to a validated PostgreSQL target. It uses the CLI for clarity. The desktop application drives the same engine through a graphical interface.
Before you start
- Trekport is installed. See installation.
- You have a connection string for the source Oracle and the target PostgreSQL.
- The target PostgreSQL allows the extensions listed in the compatibility layer.
1. Extract the source catalog
The extractor connects to Oracle, walks the data-dictionary views, and serializes every object into a portable catalog mirror on local disk. The mirror is human-readable and version-controllable.
trekport extract \
--source oracle://hr@oracle.internal:1521/HR \
--output ./catalogThe catalog mirrors the data-dictionary layout one to one. Tables land under ./catalog/HR/tables/, packages under ./catalog/HR/packages/, and so on. Roles, privileges, and tablespaces land under ./catalog/_database/.
2. Run the conversion
The converter reads from the catalog mirror, parses every artifact into a syntax tree, applies translation rules, and emits PostgreSQL output. The converted tree mirrors the catalog tree one to one.
trekport convert \
--input ./catalog \
--output ./converted \
--report ./reports/conversion.htmlInspect ./reports/conversion.html. Every translation decision is logged, including the rule reference, the parse-tree change, and any object that was deferred.
3. Deploy to the target
The deployer applies the converted tree to PostgreSQL in fourteen dependency-ordered phases. Failures retry across passes. Each phase emits a typed status into the deployment report. The exact phase order is documented in deployment phases.
trekport deploy \
--converted ./converted \
--target postgres://hr@pg.internal:5432/hr_target \
--phases all \
--extensions orafce,pg_cron,http4. Transfer the data
Data transfer runs after the schema has landed. Temporal and binary columns route to the correct loader path automatically. Other tables use the high-throughput bulk-load path. The transfer is idempotent on the target.
trekport transfer-data \
--source oracle://hr@oracle.internal:1521/HR \
--target postgres://hr@pg.internal:5432/hr_target \
--parallelism 8 \
--validate5. Validate
Validation checks row counts, sample-row equivalence, and smoke queries against the source. The output is a signed validation report — the artifact for change-management review.
trekport validate \
--source oracle://hr@oracle.internal:1521/HR \
--target postgres://hr@pg.internal:5432/hr_target \
--output ./reports/validation.htmlWhat you get
| Output | Location | Purpose |
|---|---|---|
| Catalog mirror | ./catalog/ | Inspectable serialization of the Oracle source. |
| Converted output | ./converted/ | The deployable PostgreSQL tree. |
| Conversion report | ./reports/conversion.html | Every translation decision, by object. |
| Deployment report | ./reports/deploy.html | Per-phase status and classifier buckets. |
| Validation report | ./reports/validation.html | Row counts, checksums, and sample equivalence — the cutover artifact. |
Re-running
Every stage is idempotent against a clean target. Re-running the same inputs against the same target produces a deploy report with zero changes. This is the contract that makes Trekport safe to rehearse against staging environments.

