Assess an Oracle estate and convert its schema from an offline dump. The tool never connects to your database.
$ pip install pgrecon
Extract. Your DBA runs one read-only SQL*Plus script
(pgrecon script writes it; it is short enough to audit line by
line) and sends back a folder of spool files. Works against Oracle 9.2
through 21c; nothing else leaves the building.
Assess. The dump loads into a local SQLite inventory. Stored code is parsed with a full PL/SQL grammar, not regexes, and 76 compatibility rules produce findings with line-level evidence and a written remedy each. An effort estimator prices the migration in person-day ranges and prints its assumptions, so the number can be argued with line by line.
Convert. Schema structure becomes PostgreSQL DDL, offline:
tables, keys, indexes, views, materialized views, triggers, and the routines
it can prove equivalent - plain PostgreSQL, no compatibility extension.
pgrecon runbook writes the data-movement artifacts: a data-only
ora2pg configuration, row-count validation SQL for both engines, and the
cutover checklist.
The converter never emits DDL PostgreSQL would reject, and never drops an object silently. Everything it declines becomes one line in a residue report: the object, the reason. From a real run:
view CO.PRODUCT_REVIEWS: uses JSON_TABLE, which PostgreSQL adds in version 17 with different clause syntax; rewrite the view by hand trigger RECON_TEST.TRG_EMP_AUDIT: runs an autonomous transaction; redesign with dblink or a queue (line 5) trigger RECON_TEST.TRG_EMP_SAL_GUARD: compound triggers combine timing points; restructure as separate triggers by hand column RECON_TEST.LEGACY_REFS.SCAN_DOC: external file locators have no counterpart
The residue report is the complete work list a migration plan is priced from, produced before anyone touches production.
Nine schemas - Oracle's official HR, OE, and CO samples, plus utPLSQL, PLJSON, Logger, Alexandria, and two lab schemas - converted by each tool, then applied statement by statement to a live PostgreSQL 16. Errors are statements PostgreSQL rejected. August 2026.
| Converter | Apply errors | Notes |
|---|---|---|
| pgrecon 0.5 | 0 | every decline a named residue line |
| CYBERTEC ora_migrator | 40 | plus two whole-schema crashes; PL/SQL out of scope by design |
| Ora2Pg v25 | 77 | needed two accommodations to apply at all |
| EDB Migration Toolkit 55.13 | 135 | entire package libraries silently omitted, reported as success |
| AWS SCT | 481 | surviving objects depend on the aws_oracle_ext runtime extension |
The claim, precisely: across these nine schemas the converter emitted zero statements PostgreSQL rejected, and everything it cannot prove is a named line in the residue report. It does not mean everything converts: 51 percent of all objects converted mechanically, above 90 percent on the business-shaped schemas, and the gap is dominated by object types and packages, which nothing converts mechanically. One hierarchical view was additionally verified row-for-row against a live Oracle database running the original. Methodology, tool versions, per-tool accommodations, and how to reproduce it.
The enterprises that most need to leave Oracle are often the ones running versions nobody dares touch. pgrecon ships a second extraction script for Oracle 9.2 through 11.1: it runs on the ancient SQL*Plus already on the host, reconstructs DDL from the catalog where DBMS_METADATA falls short, respects pre-10.2 output limits, and degrades cleanly where old servers lack a view - a 9.2 dump simply carries fewer files, never an error. The rest of the pipeline is identical, and the assessment it produces is the same document: sample report from a live Oracle 11.2.0.2 database (PDF), extracted with the legacy script end to end.
A real extraction dump from Oracle XE 21c ships in the repository:
pip install pgrecon git clone https://github.com/Muzzammil242/pgrecon cd pgrecon pgrecon load examples/dump_oracle21c --db sample.db pgrecon report --db sample.db --remedies pgrecon estimate --db sample.db pgrecon convert --db sample.db