Oracle to Postgres Migration: Real Cost and When to Hire

IT and data leaders usually come to us with the same trigger: the Oracle support renewal is on the calendar again, and someone has asked why the company is still paying it. Moving to PostgreSQL is a well-worn path, and the tooling is good. But the license savings are the easy part of the math. The cost that decides whether the project succeeds is the engineering work to convert code, prove the data is right, and cut over without breaking the applications that depend on it.

This guide covers what drives the cost, the phases and what sets their length, what ora2pg automates and what it doesn’t, how to cut over, where to run PostgreSQL, and when an outside team pays for itself.

What does Oracle cost you today?

Start with the bill you already pay. Oracle’s Technology Global Price List, dated September 15, 2026, lists Oracle Database Enterprise Edition at $47,500 per processor license, with Software Update License & Support at $10,450 per processor per year, which is 22% of the license price. Options such as Partitioning, Advanced Security or Real Application Clusters are priced on top, per processor, with their own support.

Three things make the real number differ from the list:

• Processor counting. Oracle defines a processor by its own rules for physical cores and virtualized hosts, so the count can be higher than you expect, especially on VMware or cloud instances.
• Negotiated discounts. Most enterprises don’t pay list. Support is usually calculated on what you actually paid, and it tends to rise over time.
• Audit exposure. Options turned on but not licensed, or databases on hosts nobody counted, are a common finding. An honest inventory is part of any migration assessment, and it often changes the business case.

PostgreSQL itself has no license fee. You still pay for hosting, support if you want a vendor behind you, and the people who run it, but the per-processor bill goes away.

What drives the cost of an Oracle to Postgres migration?

The engineering cost depends far more on how much logic lives inside the database than on how much data it holds. In rough order of impact:

1. PL/SQL volume and style. Packages, triggers, stored procedures and functions all need conversion and testing. A database used as a plain data store moves quickly. One with business logic in packages is a software project.
2. Oracle-specific features. Advanced Queuing, Oracle Text, Spatial, database links, materialized view refresh groups, DBMS_* packages and scheduler jobs each need a PostgreSQL equivalent or a redesign.
3. Application SQL. Embedded SQL in Java, .NET or reporting tools often uses Oracle syntax and has to change with the database.
4. Downtime tolerance. A weekend outage allows a simple dump-and-load. Near-zero downtime needs change data capture, dual-running and more testing.
5. Data volume and shape. Large LOBs, very large tables and odd character sets slow the data move and the validation.
6. Testing depth. Regulated or revenue-critical systems need row-level validation and performance testing, and that usually takes longer than the conversion.

How long does it take to migrate an Oracle database to PostgreSQL?

The timeline follows the same six phases on every project. Their length depends on the cost drivers above, which is why we don’t quote a duration before an assessment.

1. Assessment. Inventory schemas, objects, PL/SQL lines, features in use, application dependencies and licenses. ora2pg’s assessment report estimates migration effort per object type and is a good first pass.
2. Schema conversion. Tables, indexes, constraints, sequences, views and partitions, translated and reviewed by a person.
3. Code conversion. PL/SQL into PL/pgSQL, plus application SQL. This is usually the longest phase.
4. Data migration. Bulk load, then ongoing replication if the cutover needs it.
5. Testing. Functional tests, row counts and checksums, query results compared side by side, and performance under real load.
6. Cutover. Freeze, final sync, switch connections, watch closely, and keep a rollback path until you trust the new system.

What does ora2pg automate, and what doesn’t it?

ora2pg is the standard open-source Oracle to Postgres migration tool. It connects to Oracle, exports the schema as PostgreSQL DDL, converts a good share of PL/SQL to PL/pgSQL, and loads data. Its assessment mode is useful for scoping before anyone commits to a budget. AWS’s Schema Conversion Tool does similar work for AWS targets.

What the tools get you is a strong first draft. These are the places where people still have to read and fix the code:

• PL/SQL packages. PostgreSQL has no packages. ora2pg maps a package to a schema of functions, but package-level variables, initialization blocks and private state need a redesign.
• NULL vs. empty string. Oracle treats an empty string as NULL. PostgreSQL doesn’t. Any WHERE col IS NULL, concatenation or NVL that relied on Oracle’s behavior can return different results with no error, which is why this one causes so many bugs.
• Sequences and identity. Sequences convert cleanly, but seq.NEXTVAL calls, trigger-based keys and the final sequence values at cutover all need checking. Newer schemas can use PostgreSQL identity columns instead.
• Data types. Oracle NUMBER without precision maps to numeric, which is slower than integer or bigint where those fit. Oracle DATE includes a time of day, so it maps to timestamp, not PostgreSQL date. Choosing types column by column affects both correctness and speed.
• Outer join syntax. Oracle’s old (+) join notation has to become ANSI LEFT JOIN / RIGHT JOIN. ora2pg rewrites many cases, but complex ones need review.
• Autonomous transactions. PostgreSQL has no PRAGMA AUTONOMOUS_TRANSACTION. Audit logging that depends on it needs a workaround, such as a separate connection through an extension, or a design change.
• Optimizer hints. Oracle hints are ignored by PostgreSQL. Queries that were tuned with hints need to be re-tuned with indexes, statistics and query rewrites.

The PostgreSQL docs have a chapter on porting from Oracle PL/SQL that is worth handing to every developer on the project.

Planning an Oracle to Postgres migration? Axio Intelligence provides Oracle database migration services, from assessment to cutover. We size the work with ora2pg, convert the PL/SQL your tools can’t, and run the testing and cutover. Book a scoping call.

How do you cut over without a long outage?

There are two common approaches:

• Dump and load. Stop writes, export, load, validate, switch. Simple and low-risk if the business can accept the downtime window.
• Change data capture and dual-run. Do a bulk load, then stream ongoing changes from Oracle to PostgreSQL until you switch. AWS Database Migration Service supports Oracle as a CDC source, and Google’s Database Migration Service offers Oracle to PostgreSQL migration. Open-source options such as Debezium do the same on your own infrastructure.

With CDC, the switch becomes a short freeze and a final sync instead of a long outage. Whichever you choose, rehearse it on a copy of production, fix the sequence values, compare row counts and checksums, and agree in advance on what would trigger a rollback.

Where should PostgreSQL run after the migration?

Pick the target early, because it changes the tooling and some of the code:

• Amazon Aurora PostgreSQL or RDS for PostgreSQL, if you’re on AWS and want managed backups, failover and patching.
• Azure Database for PostgreSQL, if your applications and identity already live in Azure.
• Google Cloud SQL for PostgreSQL or AlloyDB, if you’re on Google Cloud. AlloyDB targets heavier analytical and transactional mixes.
• Self-managed PostgreSQL on your own servers or VMs, for air-gapped sites, data that can’t leave your facilities, or when you want full control of extensions and versions.

Managed services limit which extensions you can install, so check that anything your converted code depends on is supported before you commit.

When should you hire an Oracle to PostgreSQL migration consultant?

Doing it in-house makes sense when the database is mostly tables and simple queries, your team has PostgreSQL experience, and there’s no hard deadline. Many teams handle that well with ora2pg and the PostgreSQL docs.

Outside PostgreSQL consulting services pay off when:

• There’s a lot of PL/SQL. Packages and triggers with business logic are where projects stall, and experience with the common conversion problems saves the most time.
• Downtime is tight. CDC, dual-running and rollback plans take practice to get right the first time.
• A renewal or audit date is fixed. Missing the date can mean paying another year of support.
• Your team has to keep running production. The people who know the Oracle system best are usually the busiest, and they can’t also do the migration.
• You need an independent assessment. A clear inventory and effort estimate makes the business case credible to finance.

A good firm should leave your team able to run PostgreSQL afterward, with the conversion patterns, tests and runbooks documented.

FAQ

Is ora2pg enough for an Oracle to Postgres migration?

It’s enough for schema export, data loading and much of the PL/SQL conversion, and its assessment report is the best place to start. It won’t redesign packages, fix NULL vs. empty-string logic or re-tune hinted queries. People still have to do that.

What are the best Oracle to Postgres migration tools?

ora2pg is the standard open-source choice. AWS Schema Conversion Tool and AWS DMS cover schema and data for AWS targets, and Google’s Database Migration Service covers Oracle to PostgreSQL on Google Cloud. Debezium handles change data capture on your own infrastructure.

Does PostgreSQL support PL/SQL?

Not directly. PostgreSQL uses PL/pgSQL, which is similar but not the same. Code has to be converted, and packages, autonomous transactions and some built-in Oracle packages have no direct equivalent.

How much does Oracle Database Enterprise Edition support cost?

Oracle’s September 15, 2026 price list shows $10,450 per processor per year for Software Update License & Support on Enterprise Edition, 22% of the $47,500 processor license. What you pay depends on your contract and discounts.

Can we migrate with near-zero downtime?

Yes, usually. A bulk load followed by change data capture with AWS DMS, Google’s Database Migration Service or Debezium keeps PostgreSQL in sync until a short final switch. It needs rehearsal and a tested rollback plan.

Talk it through

If you’re weighing a move off Oracle and want an honest read on the effort before you commit a budget, we’re happy to look at it with you. Book a scoping call and bring your object counts or an ora2pg report if you have one.