Leaving Oracle: The PostgreSQL and Aurora Business Case

The Oracle licence and its perpetual support annuity, not the database engine, are what a migration to PostgreSQL removes. The case turns on one question: does the re-platform effort pay back from the support you stop paying?

Prepared by Redress Compliance · July 2026 · Oracle licensing advisory. Representative Oracle estate scenario (benchmark scenario, not a quote).

The value of leaving Oracle is not a faster database. Open-source PostgreSQL is a capable engine, but the business case rarely rests on performance. It rests on what you stop paying. A migration removes three recurring costs at once: the Enterprise Edition licence, the priced options and management packs layered on it, and the 22 percent support annuity that renews every year against the full net licence, typically with an annual uplift.

That annuity is the heart of the case, because it never ends. A perpetual Oracle licence is paid once, but its support is paid forever, and it is the single largest line in most mature Oracle estates. Migration is the only move that removes it entirely, as opposed to third party support, which reduces it, or renegotiation, which slows its growth.

The table makes the framing explicit: the sunk licence is not the prize, and treating it as one understates the case. The prize is the recurring lines — the support annuity above all — that a migration switches off permanently. That is why the payback is measured against what you stop paying every year, not against what the software once cost.

The one-time cost is a re-platform, and its size is driven by how much Oracle-specific logic lives in the database. Two tools frame most migrations: the AWS Schema Conversion Tool, which converts the schema and flags the PL/SQL that will not translate automatically, and the AWS Database Migration Service, which moves the data with limited downtime. The effort concentrates in three places.

• Schema and code conversion. Tables and simple logic convert largely automatically; stored procedures, packages, triggers, and Oracle-specific SQL are where manual effort lands.
• Application and integration changes. Anything that speaks Oracle SQL or relies on Oracle behaviour — drivers, ORMs, reports, batch jobs — must be adjusted and retested.
• Testing and cutover. Functional parity, performance validation, and a rehearsed cutover are the bulk of the risk and a real share of the cost.

The destination then carries a run rate. Aurora PostgreSQL and RDS for PostgreSQL price on compute and storage with no Oracle licence in the rate, which is why the ongoing cost falls even before the support annuity is counted.

The case is a payback calculation. Take a representative estate that pays $800,000 a year all in to run Oracle — support plus the Oracle-specific infrastructure and management. A migration costs $900,000 one time and lands on Aurora PostgreSQL at $250,000 a year to run. The cumulative cost of staying and migrating cross early.

Reduced to two numbers, the case is a one-time cost weighed against a permanent saving. The migration is paid once; the saving recurs every year the estate would otherwise have carried Oracle support.

The payback assumes a manageable conversion, and not every workload delivers one. Segmenting the estate by conversion difficulty is the step that keeps the business case honest.

The counter move is to migrate the low and medium tiers first, bank the support saving they release, and use it to fund the harder databases — or to leave the hardest on Oracle deliberately, with a much smaller and more negotiable footprint.

PostgreSQL has three common destinations, and they trade managed convenience against control and cost.

• Amazon Aurora PostgreSQL. A managed, cloud-native engine with PostgreSQL compatibility, high availability, and storage that scales automatically. Lowest operational effort, priced at a premium to plain RDS.
• Amazon RDS for PostgreSQL. Managed community PostgreSQL, a step down in price and in built-in scale from Aurora, and the closest to a like-for-like managed replacement.
• Self-managed PostgreSQL. Lowest licence and service cost, highest operational burden, appropriate where the team has the depth to run it.

None carries an Oracle licence, which is the point. The choice among them is an operating-model decision made after the migration case clears, not a reason to defer the case.

The strongest reason to build the migration case is not always to execute it. Oracle prices a renewal on the assumption that the customer is captive, and a credible, costed migration plan removes that assumption. A customer who can show a board-ready business case to leave negotiates a renewal from a fundamentally different position than one who cannot.

In practice, the migration analysis pays for itself twice: once if you migrate and shed the annuity, and once if you stay and use the plan to win a materially better renewal. The worst position is the one with no analysis at all, because it is the only one Oracle can price with confidence.

The leverage is strongest when the plan is concrete rather than rhetorical. A statement that the organisation is “considering alternatives” changes nothing; a segmented estate, a costed conversion for the clean tiers, and a named destination change the negotiation entirely, because they demonstrate that leaving is an executable project rather than a threat. The work that builds the migration case is the same work that builds the renewal leverage, which is why it is worth doing before the renewal, not after it has been signed.

The common advice is that re-platforming off Oracle is too risky and too expensive to justify. We disagree, at least as a blanket claim.

The risk is real for the hardest databases, but it is routinely overstated for the majority of an estate, which is simple schema and light logic that modern tooling converts with limited effort. In the estates we reviewed, the error was usually to treat the whole estate as if it were the hardest database in it, and so to reject a migration that the low and medium tiers would have paid back quickly. Treating a mixed estate as uniformly hard is how a fixable annuity becomes a permanent one.

The counter move is to segment, migrate the tiers that convert cleanly, and price the hard tier honestly rather than letting it veto the whole case.

Migration is the only move that removes the Oracle support annuity rather than slowing it. Built well, the case pays back if you leave and wins a better renewal if you stay.

A migration programme that pays back runs on a sequence, and the sequence is what keeps the business case honest as it moves from analysis to execution.

Benchmark ranges: Redress Compliance advisory engagement file. Migration tooling per AWS Schema Conversion Tool and Database Migration Service documentation. Destination pricing per AWS published rates in force at publication.