Oracle to AWS: keep Oracle, or leave the license bill behind.

IWhy teams move Oracle to AWS: almost always the license bill

Performance is rarely the reason. Oracle is an excellent database. The reason is the cost structure: per-core licensing, support renewals, separately licensed options, and audit exposure that grows with every CPU.

Oracle Database Enterprise Edition lists at about $47,500 per processor license on Oracle's public price list, and Oracle's core-factor table often counts one physical core as more than one processor. Support adds about 22% of the license price every year. Then come the options many schemas depend on (Partitioning, Advanced Compression, Diagnostics and Tuning Packs, Active Data Guard, RAC), each licensed separately. Running on your own hardware adds the refresh, DBA headcount and a DR site, and running under a hypervisor invites the audit argument about licensing every core in the cluster.

AWS changes the structure in three ways. Keep Oracle but stop running the hardware, with RDS for Oracle. Keep Oracle Exadata and RAC, running inside AWS, with Oracle Database@AWS. Or re-platform to Aurora PostgreSQL, and the Oracle license line goes away.

Knowing which database deserves which path is the whole game, and the rest of this page is organized around that call.

IIThe three paths: RDS for Oracle, Oracle Database@AWS, Aurora PostgreSQL

In AWS 7 Rs terms, RDS for Oracle and Oracle Database@AWS are rehost or relocate (same engine), and Aurora PostgreSQL is replatform (different engine). The effort, risk and payoff differ a lot.

Decide per database. Some Oracle databases are so wired into PL/SQL, Oracle-only SQL and vendor support matrices that converting them costs more than the license they would save. Defaulting everything to RDS for Oracle carries the whole Oracle bill into AWS.

IIIAWS SCT: schema conversion and the honest assessment

The Schema Conversion Tool is where an Oracle to Aurora project succeeds or stalls, because its assessment report tells you, object by object, what converts automatically and what does not. That report is your project plan.

Point SCT at the Oracle source and the Aurora PostgreSQL target. It analyzes tables, indexes, views, sequences, constraints and the procedural code (packages, procedures, functions, triggers), converts what it can, and rates every remaining action item simple, medium or complex. The share that converts automatically depends almost entirely on how much PL/SQL you have and how Oracle-specific it is.

Storage objects and most datatypes convert cleanly (NUMBER to numeric or integer types, VARCHAR2 to varchar, CLOB to text, BLOB to bytea), with flags on NUMBER columns whose precision needs a human decision. The hard parts are predictable:

• Packages. PostgreSQL has no package construct. SCT turns each package into a schema of functions; package-level state and overloading need manual work.
• Autonomous transactions. PRAGMA AUTONOMOUS_TRANSACTION has no direct PostgreSQL equivalent and usually means redesigning the logging or audit pattern that relied on it.
• Hierarchical queries. CONNECT BY and START WITH become recursive CTEs (WITH RECURSIVE). SCT handles many; complex ones need review.
• Sequences and identity. seq.NEXTVAL maps to nextval('seq'), but identity patterns and the triggers around them often need adjusting.
• Built-in differences. DECODE to CASE, NVL to COALESCE, SYSDATE semantics, ROWNUM to LIMIT or row_number(), and Oracle treating an empty string as NULL all differ in small ways.
• Bulk operations and collections. BULK COLLECT, FORALL and associative arrays have no one-to-one mapping and are common rewrite targets in heavy ETL packages.
• Oracle-only features. Materialized-view refresh rules, some partitioning strategies and any reliance on Oracle-only options show up here as complex items.

For the hardest objects, SCT can deploy an extension pack that emulates some Oracle functions on PostgreSQL. Treat that as technical debt to revisit: convert what converts, rewrite the medium and complex items into idiomatic PL/pgSQL, and keep emulation for the long tail.

The most useful output is the number. "This database is 88% auto-convertible with 240 complex action items" lets you size the project honestly. A reporting database that converts almost fully is a quick win. A core schema with thousands of lines of PL/SQL is a real engineering program and may belong on RDS for Oracle instead.

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

Once the schema exists on Aurora, Database Migration Service moves the data and keeps it moving. Change data capture is what turns a weekend-long cutover into a switch measured in minutes.

A DMS task first copies existing data (the full load), then reads Oracle's redo logs and applies every insert, update and delete to Aurora continuously. Aurora trails production by seconds while Oracle stays fully online, so you can validate, performance-test and run the application against Aurora in staging for days or weeks.

DMS moves rows, not procedural code (that is SCT's job). Secondary indexes and constraints are usually created after the full load for speed, large-object columns need explicit LOB settings, and big or busy databases need a right-sized replication instance and often several parallel tasks. That is routine for a partner who has done it before.

VCutover and risk management for a mission-critical database

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

The answer is a rehearsed runbook and a rollback you do not have to invent under pressure. Keep the Oracle source untouched and authoritative until the cutover succeeds. Because DMS syncs Aurora from Oracle, not the other way around, rollback during the window is just pointing the application back at Oracle.

• Days before: Aurora is live under CDC and trailing Oracle by seconds. The regression suite is green against Aurora, DMS validation is clean, and query plans and indexes are tuned at production load, because PostgreSQL's planner behaves differently from Oracle's.
• The cutover window: Announce a short maintenance window. Stop application writes to Oracle. Let DMS apply the final changes. Run the reconciliation checks. Point the connection strings at Aurora.
• Smoke test: Run the critical write paths (login, checkout, the core transactions) against Aurora before reopening to users. A scripted test takes minutes and catches the typo class of failure.
• Go or no-go: If the smoke test passes, reopen traffic and watch closely. If not, point back to Oracle, reopen and debug Aurora offline. Rollback costs minutes, not data.
• Stabilize, then decommission: Keep Oracle running read-only as a safety net for an agreed window, commonly one to four weeks, then decommission it and stop the license renewal. That date is when the savings start.

VIThe license-savings model that justifies the project

The conversion costs real engineering time, so the business case has to clear it. For a high-cost Oracle database it usually does, because the Oracle bill it removes recurs every year while the conversion is paid once.

Build the model on three lines. The Oracle cost you remove: licenses after the core factor, about 22% a year in support, the options you license, plus hardware and DBA effort if you run it yourself. The Aurora cost you add: compute (instances or Aurora Serverless v2), storage, I/O and backups, with no license layer. The one-time conversion cost: SCT and DMS work, PL/SQL rewrites, testing and cutover. That last line is what MAP funding can offset when the migration qualifies.

The savings are largest when you were on Enterprise Edition with options and a DR standby, because Aurora includes Multi-AZ, backups and read replicas without per-feature licensing. They are smaller if you were already on Standard Edition. The support renewal alone can pay back the conversion, which is why these projects survive CFO review.

Two caveats keep the model honest. PostgreSQL is not a drop-in Oracle, so budget for conversion and a tuning phase (query plans, indexing, connection pooling). And savings start only after decommission: while Oracle runs in parallel as a safety net, you pay for both.

VIIWho files the funding, and when it applies

You do not have to build an SCT and DMS team from scratch. CloudRoute matches you with a vetted AWS partner who has migrated Oracle before. If the move is onto AWS and qualifies, that partner files MAP funding for it.

MAP (the AWS Migration Acceleration Program) has three phases. Assess builds readiness and a TCO model: the partner runs SCT against your Oracle databases for the convertibility numbers and a cost model, so you have go/no-go data before you commit. Mobilize builds the landing zone and a pilot conversion. Migrate & Modernize is the production conversion and cutover. Your matched partner files the MAP request when the migration qualifies, and AWS decides the amount. For startups, partner-filed funding is typically $50K to $150K. Depends on the workload; AWS approves.

The honest framing: MAP is for moves onto AWS, such as Oracle on-premises or in another cloud. If your Oracle already runs on EC2 or RDS, a move to Aurora stays inside AWS and is not a MAP migration. For Oracle Database@AWS, ask your partner how funding applies before you plan around it; AWS decides. Where no funding applies, a partner who has done Oracle to Aurora moves still de-risks the cutover.

CloudRoute is the match. You tell us how much Oracle you run, which editions and options, what the databases do and your timeline, and we introduce a partner with an Oracle migration track record that can file MAP. CloudRoute is free for you. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.