Ora2Pg, AWS DMS Schema Conversion or an AI Agent? Choosing Oracle to PostgreSQL Migration Tools and a Cutover You Can Roll Back

Choose tools by layer, not one tool for everything. For the schema, Ora2Pg (open source) or AWS DMS Schema Conversion will convert most tables, indexes, views and a good share of PL/SQL, and flag what they can’t. Assessment tools such as Ora2Pg’s cost report or the new open-source pgrecon size the leftover work before you commit a budget. The SQL embedded in Java, Python or shell scripts needs its own pass, which is where AI code agents have recently made a real difference. For the data, run a full load plus change data capture (CDC), then keep reverse replication from PostgreSQL back to Oracle after cutover so you can roll back without losing a transaction.

If you’re still deciding whether to leave Oracle at all, start with our Oracle to Postgres cost post. This one is for teams that have decided and now need tools and a cutover plan.

What does each Oracle to PostgreSQL tool actually convert?

Tool	What it does well	What it leaves to you
Ora2Pg	Free and open source. Connects to Oracle, extracts structure and data, generates PostgreSQL SQL scripts, and produces a migration cost assessment	Package state, autonomous transactions, complex PL/SQL, app-embedded SQL
AWS DMS Schema Conversion	Converts Oracle schema objects to Aurora or RDS PostgreSQL DDL with a rules engine and flags objects needing manual work	Same categories; tied to AWS targets
pgrecon	Apache-2.0, public since Oct 22, 2026. Works offline from a read-only SQL*Plus dump, runs 80 rules with line-level evidence, estimates effort in person-day ranges, and emits DDL only for what it can prove (for example, CONNECT BY becomes WITH RECURSIVE)	Everything in its “residue report”; it’s young (release 0.7.3)
AI code agents	Finding and rewriting Oracle SQL embedded across many languages, with test-and-retry loops	Business sign-off, testing, anything the tests don’t cover

A few notes on the table:

• Ora2Pg is the default starting point. It’s free, mature and widely used, and its assessment report is a quick way to size a schema. The PostgreSQL wiki’s Oracle conversion page collects many of the manual fixes.
• DMS Schema Conversion fits when the target is Aurora or RDS and you plan to use DMS for the data too. In The New York Times migration below, AWS reports it automated most of the schema objects and flagged the rest.
• pgrecon is worth a look for assessment when you can’t connect a tool to production, because it never connects to either database. Its benchmark claim (423 statements from Oracle sample schemas, zero rejected) is the project’s own, so test it on your schema.

What do the tools leave for people to fix?

Every tool above stops at roughly the same places:

• PL/SQL packages with package-level variables and initialization code. PostgreSQL has no packages.
• Autonomous transactions (PRAGMA AUTONOMOUS_TRANSACTION), often used for audit logging.
• CONNECT BY edge cases. Simple hierarchies convert to WITH RECURSIVE; NOCYCLE, SYS_CONNECT_BY_PATH and ordering rules need review.
• NUMBER precision. Unqualified NUMBER becomes numeric, which is correct but slow where integer or bigint would do.
• Empty string vs NULL. Oracle treats '' as NULL; PostgreSQL doesn’t, so results can change silently.
• SQL embedded in application code. This is usually the biggest gap. Schema tools convert the database, not the Java, Python, Go or shell scripts that send it queries.

We covered these in more depth, with examples, in our cost post.

Where do AI agents help, and what did The New York Times do?

AI agents help most with the embedded SQL. In a case study AWS published on Oct 26, 2026, The New York Times moved PLATO, its subscription revenue system, from Oracle to Aurora PostgreSQL. According to the post:

• The initial scan found about 110,000 conversion items across three schemas and more than 8,000 application files with nearly 6 million lines of code, with Oracle SQL embedded in Java, Gradle/Groovy, Python, Go and shell scripts.
• Rule-based estimates put the effort at up to 18 months. The team finished in about 5 months.
• DMS Schema Conversion handled the schema. An AI agent on Amazon Bedrock converted embedded SQL, generated parity tests and fed errors back for correction. DMS handled continuous replication.
• Before cutover, they mirrored live production traffic and ran shadow queries against PostgreSQL behind feature flags while Oracle stayed the system of record.
• At go-live they sustained 18,500 requests per second with zero revenue impact and 100% row-level data accuracy, as reported.

The lesson we’d take isn’t “let AI do it.” It’s that the team paired fast conversion with heavy verification: parity tests, shadow traffic and a rehearsed rollback.

Planning an Oracle exit and want a second opinion on tools and cutover? Book a call and we’ll review your schema, code and rollback plan with you.

How do you plan a cutover you can roll back?

Keep Oracle current after you switch, so going back is a decision, not a disaster. The pattern from the NYT case, which is the one we’d use:

1. Full load, then CDC. Load PostgreSQL, then stream ongoing Oracle changes with a CDC tool such as AWS DMS, which supports Oracle as a CDC source, until lag is zero.
2. Validate continuously. Use row-level validation (DMS has built-in data validation), compare query results, and run shadow traffic if you can.
3. Set up reverse replication before cutover. From PostgreSQL back to an Oracle copy, tested in rehearsal. NYT kept an Oracle clone current with every transaction from Aurora after go-live.
4. Pre-provision the rollback target so Oracle performs like production if you need it, and document and rehearse the rollback runbook.
5. Cut over with a short freeze: stop writes, confirm zero lag, fix sequences, switch connection strings, start reverse replication, and watch.
6. Agree on rollback triggers in advance, such as error rates, failed reconciliations or performance thresholds, and on how long you keep the reverse path running.

For the general dual-run pattern across systems, see migrating without a migration freeze.

Which tool combination should you pick?

• Small to mid-size schema, any target: Ora2Pg for assessment and conversion, an open-source or managed CDC tool for data.
• Moving to Aurora or RDS PostgreSQL: DMS Schema Conversion plus DMS for full load, CDC and reverse replication. Ora2Pg is still a useful second opinion.
• No tool access to production: pgrecon’s offline dump for the first assessment.
• Lots of SQL in application code: add a code-conversion pass, AI-assisted or not, with parity tests that compare results on both databases.

Whatever you choose, budget most of the effort for testing, reconciliation and the cutover rehearsal, not the conversion itself. That’s the work our database migration services focus on.

FAQ

Is Ora2Pg still the best free Oracle to PostgreSQL tool?

It’s the most established. Ora2Pg is free, open source and covers schema, data and a cost assessment. Newer tools such as pgrecon add offline assessment, but are much younger.

What is the difference between AWS SCT and DMS Schema Conversion?

Both convert Oracle schemas for AWS targets. DMS Schema Conversion is the managed version inside the DMS console; the Schema Conversion Tool is a desktop application. Check AWS’s current docs for which features each supports.

Can AI convert Oracle PL/SQL and embedded SQL to PostgreSQL?

It can speed up the conversion a lot, as the NYT case shows, but only alongside parity tests, data validation and human review. Treat AI output like any other unverified code.

How do you roll back an Oracle to PostgreSQL migration?

Keep reverse replication from PostgreSQL to an up-to-date Oracle copy running after cutover, pre-provision that Oracle environment, and rehearse the rollback runbook before go-live.

How long does an Oracle to PostgreSQL migration take?

It depends on schema size, PL/SQL volume and how much SQL sits in application code. NYT’s estimate was up to 18 months and it took about 5. Our cost post covers what drives the timeline.

Where to go from here

Assess first with Ora2Pg or pgrecon, convert the schema with the tool that fits your target, give embedded SQL its own pass, and design the cutover around CDC and a rehearsed reverse path. If you’d like help with any of it, book a call.