What Drives the Cost of an Oracle to PostgreSQL Migration

The short answer

Seven factors drive the effort and cost of an Oracle to PostgreSQL migration: the volume of PL/SQL, its density (how much business logic lives in the database rather than the application), the use of packages and Oracle-only features, the Oracle-specific SQL in application code, the data volume and rate of change, your downtime tolerance at cutover, and the depth of testing the business needs. ora2pg's assessment report sizes the first three per schema. The rest you estimate yourself, and a pilot migration of one representative schema is the best way to calibrate both.

The one-off migration is half the comparison. The other half is what you pay each year afterwards, which you can model with your own figures in the database support cost calculator. We do not publish effort or price benchmarks, because no two estates are alike and a borrowed number is worse than none.

The factors, and how to measure each

Three more factors scale everything above: the number of schemas and instances, the target you choose (community PostgreSQL means converting code; an Oracle-compatible distribution means converting less), and the team's PostgreSQL experience. The migration challenges post describes the Oracle-only features in detail.

How to use ora2pg's assessment

ora2pg's SHOW_REPORT export type inventories a schema and lists what cannot be exported automatically. With --estimate_cost, it gives each object a score in migration units and totals them as person-days. Its documentation says a unit represents about five minutes for a PostgreSQL expert and suggests raising the value with COST_UNIT_VALUE for a first migration. It also classifies each schema:

• Migration level A, B or C. A might run automatically, B needs code rewriting within a person-day limit, and C goes above that limit, which ora2pg describes as needing full project management. The limit is configurable with HUMAN_DAYS_LIMIT.
• Technical level 1 to 5. From 1, no stored functions or triggers, to 5, stored functions or triggers that need rewriting.

For an estate, run ora2pg_scanner with a CSV list of connections. It writes one line per schema with the assessment, plus an HTML report per database, which gives you a ranked list: A and low-numbered B schemas first, C schemas last.

ora2pg_scanner -l databases.csv -o assessment

Then correct for what the report does not count. It estimates the conversion of database objects. It does not include application SQL changes, data movement and validation, cutover rehearsals, performance tuning, operational setup such as backups and monitoring, or project management. Build those as separate line items, and calibrate the whole estimate against a pilot: migrate one representative B-level schema end to end, record the real effort per phase, and scale from that rather than from the report alone.

Downtime tolerance and the cutover method

If the business accepts an outage long enough to copy the data, the cutover is a scripted export, load and validation, which ora2pg can do with COPY and its TEST actions. If it does not, you need change data capture: a full load followed by ongoing replication, such as AWS DMS provides, then a short switch. That route costs more in tooling, rehearsals and reconciliation, and it is often the right call for customer-facing systems. Make the decision per system, not once for the estate.

Testing depth

Testing effort follows business criticality, not schema size. A small schema that calculates invoices needs more testing than a large one that stores logs. Budget for functional tests of every converted routine on a critical path, behaviour tests for the known traps (empty strings, DATE with times, implicit rollback in exception blocks), performance tests on production-sized data, and, for financial systems, a parallel run in which both databases process the same period and the totals are reconciled.

Comparing the ongoing cost

A migration case compares two running costs, plus the overlap while both systems run.

• Staying on Oracle: licences, annual support, the Enterprise Edition options and management packs in use, and the support stage of each version. Under Oracle's Lifetime Support Policy, Premier Support runs five years from general availability and Extended Support costs extra.
• Running PostgreSQL: a support contract, the operations effort for backups, failover, upgrades and monitoring, and hosting. PostgreSQL itself carries no licence fee, but someone has to patch it, including after each major version reaches community end of life.
• The overlap: both platforms run in parallel from the first migrated schema until the last one moves, so a long programme pays for both for longer.

The database support cost calculator compares the running costs using your own inputs. For managed services, factor in how version lifecycles are charged; our post on RDS Extended Support for PostgreSQL shows how that works on AWS.

Where OSSeva fits

OSSeva Assure includes Oracle-to-Postgres migration design, covering schema conversion, query compatibility analysis and the application-layer migration strategy, which is the work that turns an ora2pg report into a plan. After cutover, OSSeva for PostgreSQL supports the clusters you migrated, priced per cluster rather than per core or per node, so moving more schemas onto PostgreSQL does not raise the support bill in proportion. Patched builds cover versions past community end of life, so the PostgreSQL version you chose at the start of the programme stays supported until you choose to upgrade. See Oracle to PostgreSQL with OSSeva, or book a discovery call for a quote.

Frequently asked questions

How much does an Oracle to PostgreSQL migration cost?

It depends on the code more than the data: PL/SQL volume and density, Oracle-only features, application SQL, downtime tolerance and testing depth. Size the database code with ora2pg's assessment, add the work it does not count, and calibrate with a pilot schema.

How accurate is ora2pg's migration cost estimate?

It is a consistent way to compare schemas and to rank them, not a project budget. It covers database object conversion only, and its own documentation suggests adjusting the unit value for a first migration.

What is the most expensive part of leaving Oracle?

Usually converting and testing PL/SQL that holds business logic. Data movement is mostly automated; proving that converted code behaves identically is not.

How do we compare Oracle and PostgreSQL running costs?

List Oracle licences, support, options and packs on one side, and PostgreSQL support, operations and hosting on the other, then add the period when both run. The calculator does the comparison with your own figures.

Does a partial migration reduce costs?

It reduces what runs on Oracle. Whether it reduces what you pay Oracle depends on your contract's support terms for the licences that remain, so check them before counting the saving.