Oracle Database is one of the most capable relational engines ever built, and one of the most expensive to keep. Per-core licensing, a core factor applied to every eligible CPU, hard-partitioning rules that cap virtualization savings, mandatory support uplifts, and the ever-present risk of a license audit combine to make Oracle a perennial target for cost reduction. The good news is that the open-source and cloud-native database landscape has matured to the point where most Oracle workloads have a credible home. The catch is that “credible” depends heavily on how much Oracle-specific logic you have.
What determines your target
The single biggest factor is your PL/SQL and Oracle-feature surface area. A schema that is mostly tables, views, and portable SQL moves almost anywhere. Heavy use of packages, autonomous transactions, CONNECT BY, materialized-view refresh semantics, or RAC narrows your options and inflates the conversion effort. Assess this first, before you fall in love with a destination.
The three paths, compared
PostgreSQL is the default destination and the one most teams should evaluate first. It is a mature, standards-leaning, fully open database with an extension for almost everything, no license fee, and a deep tooling ecosystem (ora2pg does most of the mechanical conversion). Choose it when you want to eliminate licensing entirely and are willing to own the operational side or buy third-party support.
Amazon Aurora (PostgreSQL-compatible) suits teams that want out of Oracle and out of the database-operations business. You get managed backups, patching, and replicas, and AWS DMS plus the Schema Conversion Tool handle much of the lift. It is not free, it is usage-based, so model it against your steady-state load rather than assuming cloud automatically means cheaper.
MySQL fits simpler, read-heavy or web-tier workloads where you do not need PostgreSQL’s richer feature set. It is ubiquitous and easy to hire for, though its procedural language and datatype handling differ enough from Oracle to require careful conversion.
Whichever you pick, the work is schema and PL/SQL conversion, application-SQL changes, and rigorous parallel-run validation, not the data movement itself.
The parts of Oracle that are not the database
Teams scope an Oracle migration around the schema and then find the schedule consumed by everything attached to it. Three areas deserve explicit inventory in week one.
The applications you did not write. Commercial software certified against Oracle is the most common reason a migration stops halfway. An ERP or a clinical system that supports only Oracle is not a conversion problem, it is a vendor negotiation or a replacement project, and it can justify keeping a small Oracle estate alive indefinitely. Find these first, because they change the shape of the whole programme.
The integration layer. Materialized views feeding a warehouse, database links to other Oracle instances, scheduled jobs in DBMS_SCHEDULER, and Oracle-specific ETL steps tend to live outside anyone’s mental model of “the database”. They are usually straightforward to re-express, and they are almost never in the original estimate.
Operational behaviour your team relies on. Hints, optimiser behaviour, partitioning strategies, and tuned execution plans do not transfer. Queries that were fast on Oracle can be slow on PostgreSQL for reasons that have nothing to do with capability, and the fix is re-tuning rather than porting. Budget for a performance phase after functional correctness, not instead of it.
A separate point on licensing: keep your Oracle estate licensed correctly right up until the servers are decommissioned. Reducing cores or moving VMs during a migration can change your licence position, and an audit landing mid-project is a bad time to discover that.
Where Oracle earns its licence
There are workloads where staying is the right answer, and being straight about them is the only way the rest of this is credible.
Oracle’s Real Application Clusters remains genuinely distinctive for shared-storage active-active clustering, and if you depend on it, no destination here reproduces it directly. PostgreSQL’s high-availability story is good and improving, but it is a different architecture with different failure characteristics, and pretending otherwise leads to unpleasant discoveries.
Very large single-instance workloads with deeply tuned partitioning, parallel query, and Exadata offload can also be difficult to match without a redesign. If your database is measured in tens of terabytes and its performance depends on features specific to the platform, the migration is a re-engineering project rather than a conversion, and it should be costed as one.
The pragmatic middle path, and the one most large estates end up taking, is partial migration: move the long tail of small and medium databases, where the licence count is, and leave the two or three genuinely Oracle-shaped workloads where they are. That captures most of the saving for a fraction of the risk. Each path below opens to a full cost model, a phase-by-phase plan, and an in-depth guide.