pgrecon
Free, open-source migration reconnaissance. It answers the one question that decides whether an Oracle-to-PostgreSQL migration succeeds or overruns: what is actually in there, and what will it cost to move? It parses your PL/SQL with a real grammar, reports every incompatibility with file-and-line evidence, and estimates the effort in person-days — all without ever connecting to your database.
The tables are the easy part
Oracle licensing pushes organisations towards PostgreSQL, and the schema itself rarely stands in the way — tables, indexes and data move with well-trodden tooling. What sinks the timeline is twenty years of business logic: PL/SQL packages full of Oracle-only constructs that have no direct equivalent on the other side.
Migrations routinely run twelve to eighteen months and overrun their budgets for a single reason — nobody measured the code before committing to the date. The scary parts are discovered in month nine, by which point the plan is already written.
pgrecon is the measurement step. It reads the code you already have, tells you exactly which constructs will not survive the move, shows you where each one lives, and turns that into a defensible number. Run it before anyone signs anything.
We built it because we have done these migrations professionally, including for heavy-industry estates still running very old Oracle versions. The rules are the list of things that hurt us.
- Status
- v0.1.2 on PyPI · alpha
- Licence
- Apache 2.0 — free commercially
- Rules
- 62, each with fixture tests
- Analysis
- Fully offline — no DB connection
SELECTs that your own DBA reads and runs. You send back the output files; analysis happens on a laptop, against a local SQLite inventory. There is no listener to open, no account to create and nothing for a security team to sign off.
Three moves: generate, extract, analyse
The only thing that runs near production is a read-only script your own DBA inspects first.
Generate the extraction script
pgrecon script --source-version 19 writes a SQL*Plus script tailored to your Oracle release. For 9.2 to 11.1 estates, --legacy produces a variant that runs on the older dictionary views.
Your DBA reads it, then runs it
It is plain SELECT statements against the data dictionary — nothing to approve in a change board meeting. sqlplus readonly_user@service @pgrecon_extract.sql SCHEMA_NAME produces a directory of dump files. SQL*Plus is the only requirement on the database server; no Python, no agent, no network access.
Load the dump into a local inventory
pgrecon load dump_dir --db inventory.db parses the extract into a local database — every table, index, package, trigger, view, job and dependency, with the source text of each program unit.
Run the rules
pgrecon report --db inventory.db walks the parse tree with all 62 rules and prints every finding: rule ID, severity from info to blocker, the object it lives in, and the evidence. Add --remedies for what to do about each one, or --format json to feed a tracker.
Price the work
pgrecon estimate --db inventory.db converts the inventory and the findings into a low / expected / high range in person-days, and shows the arithmetic that produced it.
Decide with evidence
You now hold a defensible scope before a single line has been ported — and the same numbers can be re-run against a later extract to show progress.
Want to see it before involving a DBA? A sample Oracle dump ships with the package, so pip install pgrecon to a first report takes about two minutes with no Oracle instance anywhere.
62 rules across eight domains
Every rule ships with fixture tests, a severity, a remediation note and a documented explanation you can read with pgrecon explain RULE_ID.
| Domain | Rules | Representative findings |
|---|---|---|
| PL/SQL code | 16 | Autonomous transactions, dynamic SQL, FORALL, collections and bulk binds |
| Schema objects | 12 | Database links, scheduler jobs, materialised views, advanced queues |
| Storage | 9 | Interval partitioning, global temporary tables, bitmap indexes |
| Data types | 7 | LONG, XMLTYPE, ROWID, BFILE, TIMESTAMP WITH LOCAL TIME ZONE |
| SQL constructs | 6 | CONNECT BY, Oracle outer-join syntax, ROWNUM, MERGE |
| System packages | 5 | UTL_FILE, UTL_HTTP / SMTP / TCP, DBMS_SQL, DBMS_LOB, DBMS_OUTPUT |
| Performance | 5 | Optimiser hints, global indexes, SQL plan baselines |
| Packages | 2 | Package-level state, initialisation blocks |
Evidence, not adjectives
Each finding names the object and the location inside it, so an engineer can open the code and see the problem rather than take the tool's word for it.
Severity that means something
Findings run from info to blocker. A blocker is something with no PostgreSQL equivalent that will require a design decision — not merely a syntax difference.
A remedy per rule
--remedies prints what to do about each finding: the PostgreSQL equivalent, the extension that covers it, or the redesign it forces.
Parse failures are findings
If the parser cannot read a program unit, that is reported as a finding — never silently skipped. Unknown code is a risk, and it is accounted for as one.
Deterministic by design
Same dump in, same findings out. Two people running the same extract get the same report, which is what makes it usable in a commercial conversation.
JSON for the rest of your stack
--format json exports the full finding set for a backlog, a spreadsheet or a dashboard, so the assessment survives the meeting it was made for.
A number that shows its own arithmetic
An estimate nobody can interrogate is worth nothing in a budget meeting. pgrecon estimate builds its range from five components — baseline and environment setup, schema conversion, remediating the findings it just reported, porting PL/SQL by volume, and moving the data — and prints the contribution of each.
The output is a low, expected and high figure in person-days, with the person-month equivalent. Because the workings are visible, your team can argue with any line of it and re-run with their own assumptions instead of discarding the whole thing.
Calibration is the honest caveat: the model is built from real project experience, but it does not know your team, your test estate or your change-control overhead. That judgement is what our assessment report adds.
# estimate from the bundled sample inventory pgrecon estimate --db sample.db Components Baseline & environment Schema conversion Finding remediation PL/SQL porting (by volume) Data movement Low 108 person-days Expected 133 person-days High 183 person-days (5.1 to 8.7 person-months)
Totals from the bundled sample database; the command also prints each component's contribution. Your figures depend entirely on your own code.
The whole surface area
One command per step, and nothing hidden behind a service.
pgrecon script | Generate the SQL*Plus extraction script. --source-version targets your Oracle release; --legacy produces the 9.2–11.1 variant. |
|---|---|
pgrecon load | Parse a dump directory into a local inventory database. --encoding handles dumps that are not UTF-8. |
pgrecon report | Run all rules and print the findings. --remedies adds remediation guidance; --format json exports the full set. |
pgrecon explain | Print the full documentation for a single rule ID — what it detects, why it matters and how to resolve it. |
pgrecon estimate | Produce the low / expected / high effort range in person-days, with the component breakdown. |
# two minutes, no Oracle required — a sample dump ships with the package pip install pgrecon # or run it against your own estate pgrecon script --source-version 19 # ... your DBA runs the generated script and returns dump_dir/ pgrecon load dump_dir --db inventory.db pgrecon report --db inventory.db --remedies pgrecon estimate --db inventory.db
Full documentation, rule catalogue and issue tracker live at github.com/Muzzammil242/pgrecon.
The document that gets the budget approved
The free tool answers the engineer's question — what is in there and what breaks. The assessment report answers the board's: what does this cost, how long does it take, in what order, and what could go wrong.
What you receive
- An executive summary a non-technical sponsor can act on
- Every finding prioritised and rewritten in plain English, with business impact
- A phased migration roadmap — what moves first, what moves last, and why
- A testing and cutover plan, including how you prove equivalence
- A cost and effort estimate calibrated against real migration projects, not just the tool's model
- The risk register: what we would worry about in your specific estate
- A walkthrough call with the engineer who wrote it
How an assessment runs
- Step 1
- Your DBA runs the open-source extract — no access granted to us
- Step 2
- We analyse the dump and interview your team on context
- Step 3
- You receive the report and a walkthrough call
- Fee
- Fixed, agreed before we start
Typical turnaround is two weeks from receiving the dump. The fee is credited against a subsequent migration engagement if you choose to go ahead with us.
What it runs on
| Runtime | Python 3.11 or later, installed from PyPI with pip install pgrecon. |
|---|---|
| Source Oracle | 11.2 and later with the standard script — tested against Oracle XE 11g and 21c. Oracle 9.2 to 11.1 via pgrecon script --legacy. |
| Target | PostgreSQL. Rules are written against stock PostgreSQL, noting where an extension covers the gap. |
| On the database server | SQL*Plus only. No Python, no agent, no outbound connection. |
| Analysis store | A local single-file inventory database built from the dump. |
| Analysis method | Grammar-based parsing of DDL and PL/SQL into a parse tree — not keyword matching. |
| Output | Terminal report with severities and remedies, JSON export, per-rule explanations, effort estimate. |
| Testing | Every rule carries fixture tests; the suite runs against real Oracle extracts. |
| Licence | Apache License 2.0. Issues and pull requests welcome. |
Where this fits
Find out what the move really costs
Run the free tool yourself, or send us the dump and we will turn it into a report your board can sign off. Either way you find out before the budget is committed, not during month nine.
- Your DBA keeps control — we never ask for database access.
- A fixed fee agreed up front, credited against the migration if you proceed.
- A reply from the engineer who wrote the tool, usually within one business day.
Prefer to try it first? github.com/Muzzammil242/pgrecon · or email hello@tech-style.co.
Request an assessment
Tell us roughly what you are running and we will come back with scope and fee.