Everyone wants to leave Oracle. Very few actually leave. Understanding what you're really doing when you migrate Oracle to AWS makes the difference between a good year and a bad one.
The three real paths
Path 1: Oracle on RDS. Managed Oracle. You keep Oracle. AWS handles patching, backups, HA, minor version upgrades. You pay Oracle licensing separately (BYOL) or bundled with RDS pricing.
Path 2: Oracle on EC2. Self-managed Oracle on EC2, optionally with FSx for shared storage or on native EBS. You control the version, the patch cadence, and the licensing story completely. You also do all the ops work RDS would have done.
Path 3: Re-platform to PostgreSQL/Aurora. Actually leave Oracle. Rewrite PL/SQL to plpgsql. Break bad assumptions the app made about Oracle behaviour. Ship in 6–18 months.
Ninety percent of "Oracle migrations" I've seen were paths 1 or 2. Ten percent were path 3. Everyone talks about path 3.
When RDS is the right answer
- The workload is small-to-medium (single-digit TB).
- You're using standard Oracle features (no Data Guard, no Streams, no Advanced Security bells and whistles).
- The team doesn't want to keep a DBA on call.
- You can accept RDS's patch-window discipline.
I moved several small-to-medium databases to RDS at Rogers Bank and it was uneventful. That's the goal.
When EC2 is the right answer
- You need Data Guard, GoldenGate, ASM, or another feature RDS doesn't support.
- Licensing is BYOL and you want to keep your existing licence footprint (RDS may not honour every licensing arrangement).
- You have DBA muscle and prefer control over convenience.
- The database is close to a decade old with custom kernel parameters and undocumented tuning.
BORAL was this case. We moved Oracle databases from AWS RDS to EC2 for exactly this reason — the Data Guard configuration and the licensing arrangement didn't work in RDS. This is the boring truth of a lot of "cloud modernization" — sometimes the right architecture is more infrastructure, not less.
When re-platform is the right answer
- The app is being rewritten anyway.
- Oracle licensing is a strategic pain point at the CFO level.
- There's political capital for a 12-month project that delivers no new features.
- You can afford to write a compatibility shim for the 15% of PL/SQL that doesn't translate cleanly.
If any of those aren't true, you're going to fail at re-platforming. And that's fine — RDS or EC2 is not a failure, it's a legitimate architecture.
What DMS actually does
AWS Database Migration Service (DMS) handles the data movement. It doesn't handle the schema. For that, use the Schema Conversion Tool (SCT) — which is good for Oracle → PostgreSQL, decent for Oracle → Oracle-on-AWS, and honest about what it can't convert.
DMS's continuous replication mode is what lets you do a low-downtime cutover:
- Full load initial data (hours to days).
- CDC replication catches up (minutes to hours).
- Application writes to source; DMS replicates to target.
- Cutover window: stop writes on source, wait for DMS lag to hit zero, switch app to target, verify.
The cutover window in a properly-configured DMS setup is on the order of minutes. It gets ugly when there are LOBs, sequences, or triggers involved. All of which we had to work around at Adecco.
The parts nobody mentions
- Character set mismatches. Oracle NLS_LANG defaults are often wrong. You find this the first time a non-ASCII character shows up as
¿. Test with real production data samples, not synthetic ones. - Sequences. Oracle sequences don't replicate cleanly. Bump them up on the target ahead of cutover so there's no collision.
- Materialized views. Rebuild post-cutover, don't try to replicate.
- Advanced Queuing. If the app uses Oracle AQ, plan a separate workstream for it. Don't lump it into "the migration."
- Wallet-based encryption. Oracle TDE with wallet on-prem doesn't just carry over. Plan the KMS story before day one.
Cost expectations
- RDS Oracle SE2 is roughly the same order-of-magnitude as on-prem after 3-year Reserved Instances.
- RDS Oracle EE is expensive. Licensing dominates.
- Oracle on EC2 is cheaper on the infrastructure side, more expensive on the ops side.
- PostgreSQL re-platform is dramatically cheaper long-term, dramatically more expensive short-term.
The CFO usually likes hearing option 3. The DBAs usually recommend option 1 or 2. Both are correct from their vantage points.
Bottom line
The Oracle question is not "which AWS service" — it's "how much Oracle are we willing to keep." Answer that first, then the AWS service selection is straightforward.