// Oracle to PostgreSQL migration
Leave Oracle Database for PostgreSQL.
One team for the migration and for the support afterwards.
Replacing Oracle with PostgreSQL is a programme, not a weekend. OSSeva runs it in six stages: assessment, schema and PL/SQL conversion, data migration, a parallel run, cutover and support. We use open-source tools you can keep, such as ora2pg and the orafce extension, and the team that moved your data is the team that answers the pager afterwards. It suits teams with Oracle renewals coming up, applications they control, and a wish to run PostgreSQL on their own servers, VMs, Kubernetes or cloud account.
Trusted globally by enterprises
Why Oracle exits stall
Most teams that start an Oracle exit know where they want to land. The trouble starts in the code, the data and the months between the first test and the last cutover.
The logic lives in the database
Packages, triggers and stored procedures written in PL/SQL carry business rules that nobody has documented elsewhere. Conversion tools translate most of it to PL/pgSQL, and the rest has to be read, rewritten and tested by people who understand both dialects.
Oracle built-ins show up everywhere
Application SQL calls DUAL, NVL-style functions, Oracle date arithmetic and packages such as DBMS_OUTPUT and UTL_FILE. Some of that can be emulated in PostgreSQL with the orafce extension. The rest becomes application changes, so it has to be found before the plan is fixed.
Nobody owns the database after cutover
Migration consultancies leave when the switch is done. The application team then owns a PostgreSQL cluster, a high-availability setup and a patch cycle they have never run. That gap is where many programmes lose confidence and keep Oracle running in parallel for years.
What OSSeva delivers
Assess
An inventory of schemas, PL/SQL objects, data volumes and the applications that connect to them. Ora2Pg's migration assessment report gives a first read on effort, and we add the application-side review it cannot see. You get a written plan with a target PostgreSQL version and an order of migration.
Convert schema and PL/SQL
Tables, indexes, constraints, sequences and views converted with ora2pg, PL/SQL converted to PL/pgSQL and then reviewed by hand. Where it saves application changes, we install orafce for Oracle-compatible functions and packages, and we list every place it is used.
Migrate the data
A rehearsed load from Oracle to PostgreSQL, table by table, with row counts and checksums compared on both sides. Large tables are rehearsed until the load fits the window you can accept.
Run in parallel
The converted application runs against PostgreSQL alongside Oracle, with query results, performance and batch jobs compared. Differences are fixed before any user is moved.
Cut over
A written cutover runbook with a final sync, go and no-go checks and a tested rollback to Oracle. We run it with your team in the change window.
Support from day one
The new cluster moves straight into OSSeva support: signed PostgreSQL builds, Patroni or repmgr high availability, and on OSSeva Operate 24/7 monitoring with Critical CVEs (CVSS ≥ 9.0) patched within 48 hours and High within 7 days.
Your options, compared
| Option | What you get | Trade-off |
|---|---|---|
| Stay on Oracle | No migration risk and no code changes | The licence and support contract stay, and so does the renewal conversation. |
| Managed PostgreSQL in a public cloud | A hosted target, with AWS DMS Schema Conversion for Aurora or RDS for PostgreSQL | The database stays on that provider's service, versions and support calendar. |
| Do it yourself with open-source tools | Full control, using ora2pg, orafce and your own team | Your team carries the PL/SQL rewrite, the cutover and the PostgreSQL operations afterwards. |
| OSSeva migration and support | One team from assessment through cutover, then PostgreSQL support on your infrastructure | A services engagement followed by a subscription, priced per cluster. |
Tool capabilities from the Ora2Pg project site (ora2pg.darold.net), the orafce README on GitHub and the AWS DMS Schema Conversion user guide, checked on 7 October 2026. OSSeva coverage from the OSSeva PostgreSQL technology page. Savings depend on your own estate; the calculator uses your inputs and no assumed figures.
Frequently asked questions
What are the steps of an Oracle to PostgreSQL migration?
Six, in our process: assess the schemas and applications, convert the schema and PL/SQL, migrate and validate the data, run the old and new systems in parallel, cut over with a rollback plan, and move the new cluster into support. The parallel run is the step teams most often skip, and it is where most surprises are found.
Which tools do you use for Oracle to PostgreSQL migration?
Ora2Pg for assessment, schema conversion, PL/SQL to PL/pgSQL conversion, data export and validation, and the orafce extension where Oracle-compatible functions and packages save application changes. Both are open source, so you keep using them after we leave. On AWS, DMS Schema Conversion is another option when the target is Aurora or RDS for PostgreSQL.
How do you migrate Oracle to PostgreSQL using ora2pg?
Ora2Pg connects to the Oracle database, scans it and writes SQL scripts for the structure and the data that you load into PostgreSQL. In practice you run its assessment report first, export and review the schema, convert PL/SQL to PL/pgSQL, then export the data in rehearsals before the final load. Its data export is offline, so the final copy happens in a change window.
What are the common challenges in Oracle to PostgreSQL migration?
PL/SQL packages and triggers that need hand rewriting, Oracle built-in functions and date handling in application SQL, differences in transaction and NULL behaviour, performance plans that change on the new optimizer, and the lack of a team to run PostgreSQL once the move is done.
Can PostgreSQL replace Oracle Database?
For most OLTP applications you control, yes. Where an application depends on Oracle-only features or a vendor certifies only Oracle, staying may be the better choice, and the assessment says so.
How much will we save by leaving Oracle?
That depends on your licences, hardware and staffing, so we do not quote a figure. The database support cost calculator lets you enter your own numbers and compare.
Does OSSeva provide Oracle Database support?
No. OSSeva supports PostgreSQL and the open-source data and messaging stack around it. We help you leave Oracle and support the PostgreSQL you land on.
Who is this for?
Teams with Oracle databases behind applications they own or can change, a renewal date that gives them a reason to move, and a plan to run PostgreSQL on their own servers, VMs, Kubernetes or cloud account.
Plan your Oracle exit with the team that will support what comes after.
Book a discovery call for an assessment plan and a quote. Support is priced per cluster.