Oracle to AWS — lift-and-shift, or escape the license bill entirely.

IWhy teams move Oracle to AWS — it is almost always the license bill

Performance is rarely the reason companies leave Oracle. Oracle is an excellent database. The reason is the cost structure: per-core licensing, mandatory support renewals, expensive options, and audit exposure that grows every time you add a CPU.

Oracle Database Enterprise Edition lists at roughly $47,500 per processor license, and a single physical core often counts as more than one "processor" once Oracle's core-factor table is applied. On top of the license you pay about 22% per year in support, indefinitely. Then come the options most enterprise schemas quietly depend on — Partitioning, Advanced Compression, Diagnostics and Tuning Packs, Active Data Guard, RAC — each licensed separately, each per-core. A mid-sized Oracle estate routinely carries a seven-figure annual Oracle bill before a single new feature ships. Run it on your own metal and you add the hardware refresh, DBA headcount, and a DR standby site — and running under a hypervisor invites the recurring audit argument about whether you must license every core in the cluster, not just the ones the database touches.

AWS changes the structure in two ways. First, you can keep Oracle but stop running the metal: Amazon RDS for Oracle gives you managed Oracle (patching, backups, Multi-AZ failover) on infrastructure you rent by the hour, with Bring-Your-Own-License or license-included pricing — removing the hardware and most operational toil while leaving the Oracle license question intact. Second — the path that actually moves the cost needle — you re-platform to an open-source-compatible engine, Amazon Aurora PostgreSQL, and the Oracle license line item disappears entirely.

This is why the Oracle-to-AWS decision is really two decisions, and why the rest of this page is organized around them. Lift-and-shift to RDS for Oracle is the safe, fast move that keeps your license. Re-platform to Aurora PostgreSQL is the harder move that captures 60–90% database-cost savings. Knowing which workload deserves which path is the entire game.

IIThe two real paths: Oracle on RDS vs Aurora PostgreSQL

In the language of the AWS 7 Rs, lift-and-shift to RDS for Oracle is Rehost/Relocate (homogeneous — same engine), and moving to Aurora PostgreSQL is Replatform/Refactor (heterogeneous — different engine). The technical difficulty, the risk, and the payoff differ by an order of magnitude.

Be deliberate about which database goes which way. The instinct to "just move everything to Aurora and save the money" runs straight into the reality that some Oracle databases are so deeply wired into PL/SQL, Oracle-specific SQL, and third-party-vendor support matrices that converting them costs more than the license they'd save. Conversely, defaulting everything to RDS for Oracle because it's easy means you carry the Oracle bill into AWS and never capture the prize.

IIIAWS SCT: schema conversion and the honest assessment

The Schema Conversion Tool is where an Oracle→Aurora project succeeds or stalls, because SCT does something invaluable before you commit: it produces an Assessment Report that tells you, object by object, exactly how much converts automatically and what does not. That report is your project plan.

You point SCT at the source Oracle database and the target Aurora PostgreSQL endpoint, and it analyzes the entire schema: tables, indexes, views, sequences, constraints, and crucially the procedural code — packages, procedures, functions, triggers. It then converts what it can and flags what it cannot, classifying every action item by complexity (simple, medium, complex). The headline number — the percentage of objects that auto-convert — typically lands between 70% and 95%, and the spread between those two numbers is almost entirely about how much PL/SQL you have and how Oracle-specific it is.

Storage objects convert cleanly almost every time. Datatypes are mostly mechanical (Oracle NUMBER maps to PostgreSQL numeric/bigint/integer depending on precision; VARCHAR2 to varchar; CLOB to text; BLOB to bytea), and SCT handles the mapping, though it will flag NUMBER columns whose precision needs a human decision. The places SCT cannot fully automate are predictable, and they are the same places every Oracle→PostgreSQL migration spends its engineering hours.

• Packages. PostgreSQL has no native package construct. SCT converts each Oracle package into a PostgreSQL schema containing the individual functions; package-level state and overloading need manual handling.
• Autonomous transactions. Oracle’s PRAGMA AUTONOMOUS_TRANSACTION has no direct PostgreSQL equivalent and usually requires a redesign (e.g., dblink or a refactor of the logging/audit pattern that relied on it).
• Hierarchical queries. CONNECT BY / START WITH must be rewritten as recursive CTEs (WITH RECURSIVE). SCT handles many cases; complex ones need review.
• Sequences in DML. seq.NEXTVAL embedded in inserts maps to nextval(’seq’), but identity-column patterns and triggers around them often need adjustment.
• Built-in differences. DECODE → CASE, NVL → COALESCE, SYSDATE semantics, ROWNUM → LIMIT/row_number(), and Oracle’s empty-string-equals-NULL behavior all differ subtly.
• Bulk operations + collections. BULK COLLECT, FORALL, and PL/SQL associative arrays have no one-to-one mapping and are common rewrite targets in heavy ETL packages.
• Oracle-specific features. materialized-view refresh semantics, certain partitioning strategies, and any reliance on Oracle-only options surface here as complex action items.

For the genuinely hard objects, SCT can deploy an extension pack and, for some patterns, emulate Oracle functions on the PostgreSQL side rather than rewriting the logic by hand. That is a pragmatic accelerator, but treat emulated constructs as technical debt to revisit, not a free pass. The disciplined approach is to convert what auto-converts, manually rewrite the medium/complex action items into idiomatic PL/pgSQL, and reserve emulation for the long tail where a clean rewrite is not yet justified.

The single most useful output of this phase is not the converted schema — it is the number. Once you know "this database is 88% auto-convertible with 240 complex action items," you can size the project honestly. A 95%-convertible reporting database is a quick win. A 70%-convertible core-banking schema with thousands of PL/SQL lines is a real engineering program, and it may belong on Path A (RDS for Oracle) instead. SCT lets you make that call with data rather than optimism.

IVAWS DMS: full load, then CDC replication to a near-zero-downtime cutover

Once the schema exists on Aurora, the Database Migration Service moves the data — and, more importantly, keeps it moving. DMS’s change-data-capture mode is what turns a terrifying weekend-long cutover into a controlled switch measured in minutes.

A DMS migration task runs in up to three modes. The full load copies existing table data from Oracle into Aurora. CDC then captures every change happening on the live Oracle database — reading the redo logs — and applies those changes to Aurora continuously. Run "full load plus CDC" and DMS first bulk-copies the data, then enters a steady state where Aurora trails production Oracle by seconds. Your source system stays fully online the entire time; users never know a migration is underway.

That replication window is the heart of low-downtime migration. You let DMS keep Aurora in sync for days or weeks while you validate, performance-test, and run the application against the new database in staging. When you are confident, the cutover is simply: stop writes to Oracle, let DMS drain the last few seconds of changes, repoint the application’s connection string to Aurora, and resume. Done carefully, the user-visible downtime is minutes.

DMS is not magic on what cannot be expressed as row changes. CDC replicates inserts, updates, and deletes; it does not migrate procedural code (SCT’s job), secondary indexes and constraints are typically created after the full load for speed, and large-object (LOB) columns need explicit LOB-handling settings that trade throughput against completeness. For very large or high-change-rate databases you size the replication instance accordingly and often parallelize across multiple tasks — standard operational care a seasoned migration partner has done many times.

VCutover and risk management for a mission-critical database

The conversion and the data move are engineering. The cutover is risk management. For a database the business runs on, the migration plan is judged entirely on one question: what happens if something goes wrong at the moment of switch?

The answer is a rehearsed runbook with a rollback path that you do not have to invent under pressure. The single most important design choice is to leave the source Oracle database untouched and authoritative until after the cutover succeeds. Because DMS CDC is keeping Aurora in sync from Oracle (not the other way around), the rollback during the cutover window is trivial: if validation fails after you switch, you repoint the application back to Oracle, which never stopped being correct. You only burn that bridge once you are certain.

A typical mission-critical cutover sequence runs like this:

• Pre-cutover (days before) — Aurora live under CDC and trailing Oracle by seconds. Full application regression suite green against Aurora. DMS validation clean. Performance tested at production load — PostgreSQL’s planner behaves differently from Oracle’s, so query plans and indexing are tuned in advance, not discovered in production.
• Cutover window (the minutes that matter) — Announce a short maintenance window. Stop application writes to Oracle. Let DMS apply the final change backlog until Aurora is fully caught up. Run final reconciliation checks. Repoint connection strings / endpoints to Aurora.
• Smoke test on Aurora — Run the critical-path transactions (login, checkout, the core write paths) against Aurora before reopening to users. A scripted smoke test takes minutes and catches the connection-string-typo class of failure.
• Go / no-go decision — If smoke tests pass, reopen traffic on Aurora and monitor closely. If anything is wrong, execute rollback: repoint to Oracle, reopen, and debug Aurora offline. Because Oracle was never demoted, rollback costs minutes, not data.
• Post-cutover stabilization — Keep Oracle running (read-only) as a safety net for a defined window — commonly one to four weeks — then decommission and stop the Oracle license renewal. That decommission date is the day the savings start.

None of this removes risk entirely — a heterogeneous migration of a system the business depends on is genuinely hard — but the discipline of migrating non-critical databases first, rehearsing the cutover in staging, and keeping the rollback explicit converts an unbounded risk into a bounded, rehearsed, reversible event. That is precisely the experience you are paying a vetted migration partner for, and precisely what AWS MAP funds them to do well.

VIThe license-savings model: what actually justifies the project

The conversion costs real engineering time, so the business case has to clear it. For Oracle→Aurora it almost always does, because the recurring Oracle bill it eliminates is large and perpetual while the conversion is one-time.

Build the model on three lines. First, the Oracle cost you delete: licenses (per processor, after the core-factor multiplier), the ~22% annual support renewal, the options you currently license (Partitioning, Diagnostics, RAC, Active Data Guard), plus the infrastructure and DBA effort if you run it yourself. Second, the Aurora cost you take on: compute (instance hours or Aurora Serverless v2 capacity), storage, I/O, and backups — with no license layer at all. Third, the one-time conversion cost: the SCT/DMS work, PL/SQL rewrites, testing, and cutover — the line that MAP and database-migration funding are designed to offset.

In practice, moving a workload off Oracle Enterprise Edition with options to Aurora PostgreSQL cuts database TCO by roughly 60–90%. The savings skew higher when you were paying for expensive options and a DR standby (all of which Aurora provides natively — Multi-AZ, automated backups, read replicas — without per-feature licensing) and lower when you were already on Standard Edition. The payback period on the conversion is commonly well under a year on the Oracle support renewal alone, which is why these projects survive CFO scrutiny that kills most "modernization" initiatives.

Two honest caveats keep the model credible. PostgreSQL is not a drop-in Oracle, so budget for the conversion and for a performance-tuning phase — query plans, indexing, and connection pooling all need attention on the new engine. And the savings are real only after decommission: as long as Oracle runs in parallel as a safety net, you are paying for both. Plan the decommission date explicitly, because that date is when the recurring savings actually begin.

VIIMAP + database-migration funding: a partner runs it, AWS funds most of it

A funded, done-for-you Oracle migration is the CloudRoute mechanism. You do not assemble an internal SCT/DMS team from scratch and absorb the cost — you get matched to a vetted AWS partner who has migrated Oracle before, and AWS funding covers most or all of the engagement.

The vehicle is the AWS Migration Acceleration Program (MAP), run through the AWS Partner Network in three phases. Assess is a TCO and readiness analysis — the partner runs SCT against your Oracle databases to produce the auto-convertibility numbers and a real cost model; this phase is frequently AWS-funded and gives you the go/no-go data before you commit a dollar. Mobilize builds the landing zone and a pilot conversion of a representative database. Migrate & Modernize is the production conversion and cutover. AWS provides credits and funding scaled to the migration’s size across these phases, and there are AWS programs specifically aimed at database migrations off commercial engines like Oracle.

The honest framing matters: MAP funding applies to qualifying migrations — typically those with a meaningful committed AWS spend after migration — and the exact amount is scoped during Assess. For a substantial Oracle estate that easily clears the bar, the migration cost can be largely or entirely AWS-funded. For smaller workloads that don’t qualify for full funding, the value is still real: a vetted partner who has done heterogeneous Oracle→Aurora migrations and de-risks the cutover, rather than your team learning SCT’s edge cases live on a production database.

CloudRoute’s role is the routing. You tell us the shape of the estate — how much Oracle, which editions and options, what the databases do, your timeline — and we match you to a partner with a genuine Oracle-migration track record and the AWS tier to file MAP. The partner runs the assessment, scopes the funding, and executes. AWS funds the engagement; the partner is paid through MAP; CloudRoute is paid a commission by the partner. You see no invoice from us.