An Oracle to Aurora migration replaces a perpetually-licensed Oracle Database with Amazon Aurora — a managed, PostgreSQL- or MySQL-compatible service that carries no software licence at all. There is no Processor metric, no Core Factor, and no annual support uplift. The economic question is not whether Aurora is cheaper to run; it almost always is. The question is whether the conversion cost and feature gap fit your workload. We model both sides below.
Short answer: An Oracle to Aurora migration typically cuts five-year database run-rate by 60 to 80 percent because Amazon Aurora has no perpetual licence and no 22 percent Oracle support fee — you pay AWS only for compute, storage, and I/O. The trade-off is a one-time conversion cost, usually 30 to 80 percent of a single year of Oracle support.
Short answer: Amazon Aurora is a managed relational database service from AWS that is wire-compatible with PostgreSQL and MySQL. It carries no software licence — you pay AWS for compute, storage, and I/O — so the Oracle Processor metric, Core Factor, NUP minimums, and 22 percent support fee are removed entirely.
For an Oracle to Aurora migration, Aurora PostgreSQL-Compatible Edition is the usual target, because PostgreSQL's procedural language (PL/pgSQL) is the closest analogue to Oracle's PL/SQL and the conversion tooling is most mature. Aurora separates compute from a distributed storage layer that auto-scales to 128 TiB, replicates six ways across three Availability Zones, and is billed independently of the database engine.
The licensing contrast with Oracle is total. Oracle Database EE is licensed by Processor — physical cores multiplied by the Oracle Core Factor (0.5 on modern x86) — or by Named User Plus, then carries Enterprise Support at 22 percent of net licence value every year. Aurora has none of that. There is no perpetual licence to own, no option packs to buy separately, and no support metric. You provision an instance class (or Aurora Serverless v2 capacity units), and the meter runs only while it does.
Short answer: Oracle bills a large upfront perpetual licence plus 22 percent annual support that compounds for the life of the estate. Aurora bills only consumption — instance-hours, storage per GB-month, and I/O — with reserved-instance discounts available. The fixed, ever-rising Oracle support line is replaced by a variable, right-sizeable compute line.
The structural shift is from a capital-plus-annuity model to a pure operating-expense model. Under Oracle, the 22 percent support fee is the cost that never stops and never falls — it is charged on net licence value and rises with CPI uplifts at renewal regardless of how much capacity you actually use. Under Aurora, the recurring cost tracks workload: scale a reader fleet down overnight, move dev/test to Aurora Serverless, or buy reserved capacity for steady production, and the bill follows.
That difference is why the Oracle to Aurora migration math is so favourable on a five-year view. You are not swapping one licence for another cheaper licence — you are deleting the licence line altogether and replacing it with metered infrastructure you control. The catch is the conversion, which is real engineering work, covered below.
| Cost dimension | Oracle Database EE | Amazon Aurora PostgreSQL |
|---|---|---|
| Software licence | $47,500 / Processor (list) | None |
| Effective x86 per-core (list) | $23,750 (Core Factor 0.5) | N/A |
| Option packs (Partitioning, ADG, etc.) | Separately licensed | Included in engine |
| Recurring support / run cost | 22% of net licence, annual | Instance-hours + storage + I/O |
| Support uplift at renewal | CPI-linked, compounding | None — reserved pricing fixed |
| Virtualisation / partitioning licence trap | Full-cluster exposure on VMware | None |
Short answer: RDS for Oracle under BYOL keeps the full Oracle licence and 22 percent support — you simply run it on AWS-managed infrastructure, so the Oracle run-rate is unchanged. Aurora removes the Oracle licence and support entirely. RDS BYOL is the easier lift-and-shift; Aurora is materially cheaper long-term.
RDS for Oracle is Amazon's managed Oracle Database service. Under Bring Your Own Licence (BYOL), you must already own and maintain Oracle Database licences on active support; AWS charges only for the managed infrastructure. The Oracle compliance position still applies — including Oracle's authorised-cloud policy, which counts every two vCPUs as one Oracle Processor licence where hyper-threading is on. RDS for Oracle is therefore the right step when you need to exit your own data centre fast without changing the database engine, but it does nothing to reduce Oracle spend.
RDS for Oracle also offers a License Included option for Standard Edition Two, but not for Enterprise Edition, so EE estates are locked into BYOL. We unpack that split in detail in our guide to Oracle RDS BYOL versus License Included. Aurora is the destination when the goal is to delete Oracle cost, not relocate it — and most buyer-side migrations use RDS for Oracle (or Database@AWS) only as a staging step before converting to Aurora.
Short answer: On a 100-core Oracle Database EE estate with Partitioning, Diagnostics, and Tuning packs, the five-year Oracle run-rate models at roughly $7.6M. The equivalent Aurora PostgreSQL deployment, including a $1.2M conversion project, models at roughly $2.9M — a 62 percent reduction.
Scenario: 100 physical cores of Oracle Database EE workload, mixed OLTP and reporting, currently virtualised on-premises, using Partitioning, Diagnostics Pack, and Tuning Pack. We compare staying on Oracle against converting to Aurora PostgreSQL on right-sized instances with reserved pricing.
| Cost component | Stay on Oracle EE | Migrate to Aurora |
|---|---|---|
| Perpetual licence (already sunk) | $2.38M net (amortised) | $0 |
| Required option packs | $1.30M net | Included in engine |
| Annual support / run cost | $808K Oracle support (22%) | ~$340K Aurora compute + storage |
| 5-year recurring (4% Oracle uplift) | $4.38M | $1.70M |
| One-time migration project | $0 | $1.20M |
| Residual Oracle for non-migrated edge cases | n/a | $0 |
| 5-year total cost | $7.66M | $2.90M |
The modelled saving is $4.76M over five years, a 62 percent reduction, with the $1.2M conversion recovered inside the eleventh month of Aurora operation. The single largest driver is the disappearance of the compounding 22 percent Oracle support line — not the compute cost, which Aurora reserved pricing keeps modest. With a forced full-cluster Oracle licence position on VMware, the stay-on-Oracle column rises further and the gap widens past $6M.
Short answer: AWS Schema Conversion Tool (SCT) automates 70 to 90 percent of schema and code conversion from Oracle to Aurora PostgreSQL. The residual effort is manual PL/SQL to PL/pgSQL rewrite of packages, triggers, and proprietary functions. AWS Database Migration Service (DMS) handles the data load and change-data-capture with minimal downtime.
The conversion difficulty scales with how much business logic lives inside the database rather than the application. A schema-light estate — tables, indexes, simple views, application-side logic — converts fast and is dominated by data-move and test time. An estate with tens of thousands of lines of PL/SQL packages, autonomous transactions, hierarchical queries, and Oracle-specific built-ins requires real developer effort to rewrite, because SCT flags those constructs but cannot always translate them.
The constructs that most often need manual work in an Oracle to Aurora migration are: packages (PostgreSQL has no direct package construct, so they are refactored into schemas of functions), CONNECT BY hierarchical queries, DECODE and other Oracle built-ins, sequences used as defaults, autonomous transactions, and any reliance on Oracle Spatial, Text, or Advanced Queuing. A buyer-side estimate prices these explicitly rather than trusting the SCT automation percentage, because the last 10 to 30 percent is where the project hours concentrate.
Short answer: A disciplined Oracle to Aurora migration runs in six stages — assess, convert, move data, validate, cut over, then time the Oracle non-renewal to the contract anniversary so the licence and support spend stops cleanly on a defended position.
Short answer: Frequently, yes. Non-renewal of Oracle support triggers an LMS (now sometimes badged GLAS) engagement letter within 30 to 180 days in a large share of cases. The defence is preparation — capture the decommission evidence and final entitlement position before the non-renewal notice goes out.
Oracle's audit clause survives the support relationship. When you stop paying support and the Oracle estate goes quiet, the account team's incentive is to verify there is no residual unlicensed deployment — and to test whether the exit can be converted back into revenue. The opening claim, as in any Oracle audit, is built against the maximum-exposure reading of your contract. Across engagements, opening claims run 3 to 5 times what the customer actually owes, and settle far lower once a forensic, evidence-based defence is presented.
The buyer-side move is to treat the Aurora cut-over and the Oracle exit as one project with a documented evidence trail: decommission logs, final LMS measurement, and a clean compliance declaration filed before notice. We cover the operational mechanics in the Oracle audit defence guide and reduce ongoing exposure through Oracle support reduction. Done in this order, the exit closes without a back-licence claim.
Short answer: Aurora is a weak fit for RAC-dependent active-active workloads, estates with deep Oracle Spatial, Text, or proprietary PL/SQL package dependence, data warehouses above 100 TB, and certified SAP-on-Oracle environments. In those cases the conversion cost or feature gap usually outweighs the licence saving.
The migration math breaks when the conversion effort or a hard feature dependency exceeds the licence saving. Where it works:
Where it does not:
For estates that do not fit Aurora, the stronger buyer-side play is to renegotiate the Oracle contract or move to PostgreSQL on a self-managed footprint — modelled in our Oracle to PostgreSQL TCO model and benchmarked against the head-to-head Oracle Database vs Amazon Aurora comparison.
An automotive parts supplier ran 90 Oracle Processor licences of Database EE with Partitioning and Diagnostics Pack on an ageing VMware cluster, with a defended position covering 140 physical cores after Oracle's soft-partitioning interpretation. Annual Oracle run-rate was $3.4M. AWS SCT auto-converted 82 percent of the schema and PL/SQL; the residual 18 percent — chiefly two large packages and a set of hierarchical queries — took a four-developer team eleven weeks. The cut-over to Aurora PostgreSQL landed the annual run-rate at $0.8M, with the Oracle CSI terminated on the September anniversary. The migration cost $1.5M and was recovered inside the seventh month. The LMS letter arrived in week six of non-renewal; the prepared evidence pack closed it with no claim. Full write-up in our case studies.
An Oracle to Aurora migration typically cuts database run-rate by 60 to 80 percent over five years. Amazon Aurora carries no perpetual licence and no 22 percent Oracle support fee — you pay only for instance-hours, storage, and I/O. Across our engagements, mid-size Oracle Database EE estates that migrate to Aurora PostgreSQL land at 25 to 40 percent of the prior Oracle run-rate once conversion is complete (Oracle Licensing Experts benchmark, 2026).
Amazon Aurora is a managed relational database service from AWS that is wire-compatible with PostgreSQL and MySQL. It has no software licence: you pay AWS for compute (instance-hours or Aurora Serverless capacity), storage, and I/O. There is no Oracle Processor metric, no Core Factor, no Named User Plus minimum, and no annual support uplift — the entire Oracle licensing model is removed.
RDS for Oracle under BYOL still requires you to own and support Oracle Database licences, so it carries the full Oracle run-rate plus AWS compute. Aurora removes the Oracle licence and support entirely. RDS BYOL is the cheaper short-term lift-and-shift; Aurora is materially cheaper long-term once conversion completes, because it deletes the 22 percent annual Oracle support fee permanently.
For a typical mid-size estate, plan 9 to 18 months. AWS Schema Conversion Tool (SCT) automates 70 to 90 percent of schema and code conversion; the remainder is manual PL/SQL to PL/pgSQL rewrite. AWS Database Migration Service (DMS) handles the data move with minimal downtime. Estates with heavy PL/SQL business logic, RAC dependence, or Spatial features take longer.
Migration project cost typically runs 30 to 80 percent of one year of Oracle support spend — covering schema conversion, PL/SQL rewrite, application changes, testing, and parallel-run. In most cases the project pays back inside 6 to 14 months of operation because the recurring Oracle licence and support spend disappears entirely (Oracle Licensing Experts benchmark, 2026).
Non-renewal of Oracle support frequently triggers an LMS engagement letter within 30 to 180 days. The defence is preparation: assemble decommission evidence, capture the final entitlement position, and file the audit pack before the non-renewal notice goes out. A well-prepared exit closes without a back-licence claim; an unprepared one becomes a negotiation.
Aurora is a weak fit for RAC-dependent active-active workloads, estates with deep Oracle Spatial, Text, or proprietary PL/SQL package dependence, very large data warehouses above 100 TB, and certified SAP-on-Oracle environments. In those cases the conversion cost or feature gap usually outweighs the licence saving, and renegotiating the Oracle contract is the stronger buyer-side move.
Independence statement: Oracle Licensing Experts is an independent buyer-side advisory firm. Not affiliated with Oracle Corporation. We do not resell AWS or Oracle. All numbers above reflect published list prices and benchmark ranges from real engagements.
Audit alerts, contract tactics, TCO benchmarks, and migration intel — every two weeks. Read by ITAM leads, CIOs, and legal teams at global enterprises.
No spam. Unsubscribe anytime. Not affiliated with Oracle Corporation.
Independent, buyer-side guidance across services, guides, benchmarks and tools — explore the cloud cluster.