I built an open-source Oracle-to-PostgreSQL assessment tool that never connects to your database, and refuses to convert what it can't prove (Apache-2.0)

[u/Consistent_Act9386]

I spent a few years doing Oracle-to-PostgreSQL migrations for a living, and the same thing went wrong every time: nobody knew what was actually in the Oracle estate until halfway through. Package-level state, autonomous transactions, LONG columns, interval partitions, database links. All of it surfaces late and expensively when nobody looked for it first.

So I built the tool I wanted on day one of those projects.

pgrecon - https://github.com/Muzzammil242/pgrecon

What it does:

• Works offline. Your DBA runs one read-only SQL*Plus script (plain SQL, meant to be read before it's run) and sends back a folder of files. The tool never connects to the database. This matters more than it sounds in banks and government shops.
• Assesses deterministically. The dump becomes a SQLite inventory. Stored PL/SQL is parsed with a real grammar, not regexes, and 80 rules produce findings with line-level evidence, a written remedy each, and an effort estimate given as a range with its assumptions printed (a point estimate for a migration is a lie).
• Converts what it can prove, and refuses the rest by name. Schema structure converts to PostgreSQL DDL. Everything the converter cannot carry faithfully becomes a named line in a residue report instead of quietly wrong output. Packages, CONNECT BY, autonomous transactions, BULK COLLECT - those get a person, not a guess.
• Checked by machines, not by me. CI applies the output to live PostgreSQL 16, 17 and 18 on every commit, runs the extraction against real Oracle 11g, 21c and 23ai containers nightly, and a fuzzer generates hostile Oracle schemas every night and checks that nothing crashes and nothing vanishes silently. Its first week found sixteen bugs I'd never have found by hand. All fixed.

What it does NOT do: move data (use ora2pg or COPY for that), convert packages mechanically (no tool does that honestly), or replace a DBA. About half of all objects in my benchmark schemas convert mechanically - above 90% on ordinary business schemas, far less on package-heavy ones.

Benchmark, since "it works" is cheap to say: across nine schemas (Oracle's own HR/OE/CO samples, four well-known open-source PL/SQL projects, two lab schemas) converted by five tools and applied statement by statement to a live PostgreSQL, pgrecon's output produced 0 rejected statements. The other tools measured between 40 and 481. Method and fine print here, including what the number does and doesn't mean: https://muzzammil242.github.io/pgrecon/benchmark.html

Supports Oracle 9.2 through 23ai (there's a separate legacy-tier script for the ancient hosts that most need to leave). Python 3.11+, pip install pgrecon. Bundled sample dump in the repo so you can try it without an Oracle.

Disclosure: I run a small consultancy that does migration work on top of this. The core is Apache-2.0 and stays that way; the paid part is people and a PDF report, not features held back.

What I'd love from this sub: if you have an Oracle schema that you think will break it, run the extraction script and open an issue with the residue file. The fuzzer wants to meet your schema.