Most of your PL/SQL doesn't need rewriting.
EDB Postgres® AI (EDB PG AI) runs packages, exception handling, cursors, and Oracle-compatible data dictionary views natively. EDB testing found organizations migrating from Oracle require up to 95% fewer application rewrites.
Why compatibility can help you move off Oracle
The rewrite pain is the real blocker
Moving the data is rarely the hard part. Most Oracle migrations stall when a team estimates the work of rewriting the procedural code, such as PL/SQL packages, exception handling, and cursor logic. That estimate can be large enough to end the conversation. Compatibility layers and automated conversion tools can reduce the amount of code that has to change.
Portability you can't currently exercise
Applications written against Oracle-specific behavior, such as PL/SQL, proprietary data types, and Oracle-only features, generally can’t run on another database without changes. That ties the workload to wherever Oracle is available and licensed, which limits where the workload can run. With a compatibility layer or a code conversion, the application can run on Postgres in any environment.
Staying costs are easier to forecast than leaving costs
Oracle licensing and support costs are high but predictable. The cost of migrating is harder to estimate. That gap often keeps databases on Oracle even after the technical case for moving is clear. A migration assessment closes it by putting a number on the unknown side, so you can compare the two costs directly.
What carries over from Oracle, and what to check
EDB PG AI includes Oracle compatibility in the database server itself and can run in an Oracle-compatible mode. Oracle-style code, including PL/SQL packages, runs directly on the server instead of being converted to standard Postgres equivalents first.
Oracle construct | EDB PG AI equivalent | What to expect |
|---|---|---|
PL/SQL packages | SPL packages | The one that matters most. Community PostgreSQL has no package concept, so each one much be redesigned. EDB PG AI supports packages structurally. |
Exception handling | SPL exception semantics | Semantically aligned rather than hand-adjusted. Edge cases still need review, but the shape of the code survives. |
Cursor logic | SPL cursors | Carries across. Cursor-heavy procedural code is a review target for performance, not for correctness. |
Data dictionary views | Oracle-compatible catalog views | Tooling and admin scripts that query the Oracle data dictionary keep working. This is frequently the most underestimated dependency in an estate. |
MERGE, Oracle SQL syntax, built-in packages | Native in Oracle-compatible mode | Supported directly. |
Applications written against OCI | EDB OCL Connector | A connector for Open Client Library lets you compile applications written for the Oracle Call Interface, so you avoid rewriting the data-access layer. |
SQLPlus scripts, SQLLoader jobs | EDBPlus, EDBLoader | Operational tooling, not just the database. Existing scripts and load jobs largely carry over. |
Compatibility surfaces per EDB PG AI product documentation. Coverage depends on how much Oracle-specific behavior your code uses. Confirm with a schema assessment.
The honest edges. These are documented limits, and you will meet them during assessment rather than after:
EDB's migration tooling supports Oracle 11g, 12c, 18c, and 19c as sources. It isn’t tested with or officially supported on Oracle RAC or Exadata, though it can work when connected to a single persistent node, so talk to your EDB representative about your environment. Profiles migrate, but passwords aren't, and you assign them to users afterward.
None of these are dealbreakers on a typical estate, but all of them change a project plan. It's better to find them in an assessment now than finding them mid-migration.
Where ora2pg fits
ora2pg is a mature, free, community-maintained tool that handles many Oracle migration use cases. If you’re evaluating an Oracle migration, you probably know it already. Here is where it fits.
How much this matters depends on how much PL/SQL you have. The more Oracle code in your databases, the more rewriting the right destination saves, and an assessment shows how much you have.
How a migration runs, end to end
The same five stages, in the same order, wherever code and schema have to be converted. Assessment first, validation last, nothing skipped.
Assess
Schema and complexity analysis across the estate
Transform
Schema and procedural code conversion
Remediate
Resolve the edge cases conversion leaves behind
Move
Coordinated data transfer and sync
Validate
Integrity, correctness, and performance checks
Near-zero-downtime cutover. EDB PG AI supports ongoing Oracle-to-EDB PG AI and Oracle-to-PostgreSQL synchronization, so the move and the cutover are separable decisions. Systems that cannot take an outage run both in parallel until the switch is a business decision rather than an engineering event.
What's on the other side of the migration
Organizations that have already migrated
“We took the opportunity to modernize and to move to something lower cost—and a lot more performant than what we were getting with Oracle....Geoprocessing tasks now take 25% of the time that they did on Oracle.”
— John Lovato, Database Architect, USDA Forest Service
Ericsson migrated its content management system off Oracle to support mobile media at carrier scale. The team judged Oracle unsuited to the workload, citing limited customization and integration with newer technology against open source alternatives.
“We were looking to move away from that vendor to another solution, which would need to be more dynamic, flexible, and of course cost-effective.”
— Alfredo Palacios, Director of Application and Platform Operations for e-Commerce, Avis Budget Group
Migrated Esri GIS mapping and data-analysis workloads off Oracle, where high availability required an expensive hot-standby configuration that in many cases doubled the anticipated cost. Using EDB Postgres AI saved the Navy millions on its IT budget.
Published EDB customer stories. Figures and characterizations are as stated in each customer's own story. USDA Forest Service performance and cost figures are that customer's own estimates rather than an audited benchmark.
Where the migrated system runs
Self-managed
Run EDB PG AI on your own infrastructure, on-premises, or in your own cloud accounts.
Hybrid Manager
One control plane across on-premises and cloud estates, for organizations that aren't consolidating onto a single environment.
Managed platform
A managed service where EDB operates the platform and your team keeps the workload.
Take it to your team
Technical Migration
Playbook
Migration Governance
Runbook
Documentation
Documentation
Price the unknown side
An assessment turns the rewrite estimate from a guess into a number: package and procedural inventory, RAC and Exadata dependencies, source version, downtime tolerance. That number is what a budget conversation actually needs.