Almost every tool in this category wants live access to your production Oracle. We ask your DBA to run a script instead, and we do that on purpose.
Most Oracle assessment and migration tools start the same way. Give me a connection string, a privileged account, and a network path into production. It's the obvious design, and it's also why those tools stall at the companies that most need to leave Oracle: banks, telecoms, government offices, anyone whose security team reviews every new thing that touches production.
pgrecon never connects to your database. It gives your DBA a script. The DBA reads it, runs it under their own account, and hands back a folder of files. That folder is all pgrecon ever sees.
What the script is
It's plain SQL*Plus, about 600 lines, and it only reads. Most of it is SELECT statements against Oracle's own dictionary views. A few short PL/SQL blocks tell DBMS_METADATA to leave out storage clauses, and print long columns that plain SQL can't cut into pieces. There's no DML and no DDL in it. Nothing is written anywhere except the spool files on the DBA's own machine. A DBA can read the whole thing in one sitting, and that's the idea: they should know exactly what will run before it runs.
pgrecon never sees a password or holds a credential, because it never needed one. It works from the spool files, which load into a local SQLite inventory. The rules, the effort estimate and the converter all read from that inventory.
The standard script covers Oracle 11.2 and newer. A second script covers 9.2 through 11.1 and is written for whatever old SQL*Plus client is already sitting on that server. It rebuilds DDL from the catalog by hand where the modern metadata package doesn't exist yet, and when an old version is missing a dictionary view, it writes fewer files instead of failing. We built that tier because the companies still running 9i and 10g in production usually have the most to gain from leaving, and the least interest in handing an outside tool a live connection to find out.
Why offline wins in practice
At a large company, "this tool needs read access to our production Oracle" turns into a security review ticket. Those tickets can sit in a queue for months, and some never come back out, however reasonable the request is. The process doesn't ask whether you're reasonable. It asks whether you've been reviewed yet.
A read-only script that the DBA runs under their own account is a much easier yes. The DBA can see everything it does, and nothing leaves the building except files they've already looked at.
So we don't see offline as a limitation we have to explain away. It's what decides whether the assessment runs this month or next quarter. A live-connection mode is planned for later, for teams where the trade-off runs the other way, but it will sit next to the offline path, not replace it.
The current release is pgrecon 0.7.3. pip install pgrecon, then pgrecon script writes the extraction script to a file your DBA can read line by line before anything runs. The project page is muzzammil242.github.io/pgrecon. If a fixed-price assessment fits your organization, it starts the same way, with a script your DBA reviews first: book one at DevCrafter AI.
Top comments (0)