Source: searchaws.techtarget.com (original reporting by TechTarget/SearchAWS, published October 2019). Attribution to analyst quotes from Doug Henschen, Constellation Research, and Curt Monash, Monash Research.
Amazon Finishes Its Own Oracle-to-AWS Migration
Amazon’s consumer division has completed a multi-year effort to move its internal database workloads off Oracle and onto AWS-native database services. AWS Chief Evangelist Jeff Barr announced the completion in a blog post, describing the project as one that involved more than 100 teams across properties including Amazon Prime, Prime Video, Shopbop, Twitch, and internal business units handling payments, fulfillment, returns, deliveries, and marketplace operations.
The migration is significant for two reasons: it removes Amazon’s dependence on a direct commercial rival’s technology, and it gives AWS a first-party reference case study to present to enterprise customers considering their own Oracle exit.
Scale of the Migration
According to Barr’s blog post, the project involved approximately 7,500 Oracle database instances holding around 75 petabytes of data. That data was redistributed across several AWS-managed database services based on each team’s workload requirements:
- Amazon DynamoDB — for high-throughput, low-latency key-value and document workloads
- Amazon Aurora — for relational workloads requiring MySQL or PostgreSQL compatibility
- Amazon RDS — for managed relational database needs across multiple engines
- Amazon Redshift — for analytical and data warehousing workloads
Barr noted that some third-party software was excluded from the migration because it remained too tightly coupled to Oracle’s database engine to be moved without vendor involvement.
Claimed Performance and Cost Outcomes
Amazon published several outcome metrics associated with the migration. According to Barr’s post:
- 60% reduction in database costs compared to the negotiated Oracle license rate
- 40% reduction in latency for consumer-facing applications affected by the migration
- 70% reduction in database administrative overhead
These figures come directly from Amazon and have not been independently verified. Analyst Curt Monash of Monash Research offered a useful caution: applications that have been substantially rewritten during a migration may show performance and efficiency gains attributable to the rewrite itself, not purely to the choice of target database platform. Enterprises should weigh Amazon’s numbers in that context when benchmarking their own migration business cases.
Why This Matters for Enterprise Customers
Doug Henschen, an analyst with Constellation Research, framed the strategic importance clearly: “If customers are to believe that they can do without the world’s leading commercial database, Amazon itself better be showing the way.”
His point is that AWS selling Oracle migration services while running Oracle internally would undermine the credibility of its own tooling and managed database portfolio. By completing the migration at scale, Amazon demonstrates that:
- Its migration tooling — including the AWS Schema Conversion Tool and AWS Database Migration Service — is capable of handling complex, high-volume workloads in production.
- AWS-native database services can carry the most demanding transactional and analytical workloads without Oracle.
- The purpose-built, polyglot database model (choosing the right database for each workload rather than forcing everything into a single relational engine) is operationally viable even at hyperscale.
Henschen also pointed out that the migration is particularly telling for acquired business units such as Audible and Zappos, which were not originally built on AWS infrastructure and therefore represent a closer analogy to typical enterprise migration scenarios than Amazon’s own greenfield services.
Oracle’s Counter-Position
Oracle did not comment publicly on the migration at the time. At its OpenWorld conference held the prior month, Oracle CTO and Executive Chairman Larry Ellison positioned Oracle Database as a multi-model platform capable of handling a wide range of workloads — key-value, relational, graph, JSON document — within a single engine, arguing this approach is superior to maintaining multiple purpose-built databases.
Oracle also shifted its cloud infrastructure strategy away from competing directly for commodity compute. Instead, Oracle Cloud Infrastructure (OCI) was positioned as the preferred environment for highly critical, performance-sensitive workloads, backed by Exadata hardware. This represents a deliberate narrowing of Oracle’s IaaS ambitions toward enterprise segments where database performance is a differentiator.
The Broader AWS Go-to-Market Play
Amazon’s motivation for publicizing the migration is not purely internal. Database workloads are notoriously sticky — once applications are rewritten against a specific database API or data model, moving them again is expensive and time-consuming. Winning Oracle database migrations is therefore a high-value long-term revenue opportunity for AWS.
AWS planned to feature sessions led by migration project team members at its re:Invent conference, giving practitioners direct access to the engineers who managed the migration at scale. This is a practical knowledge-transfer strategy designed to lower the perceived risk for enterprise architects considering similar projects.
Key Takeaways for DevOps and Database Engineers
- Purpose-built databases reduce operational complexity at scale. Amazon’s DBAs reported spending excessive time on capacity management and scaling of monolithic Oracle instances. Distributing workloads across fit-for-purpose managed services shifted that burden to AWS.
- Migration gains may include rewrite benefits. As Monash noted, rewriting applications against new schemas and APIs can yield improvements independent of the target platform. Separate those gains carefully in your own ROI analysis.
- Acquired business units are a realistic proxy. Teams migrating legacy enterprise systems will find more relevant comparison in how Amazon handled Audible or Zappos-type workloads than in how it handled services built natively on AWS from day one.
- Tight Oracle integrations remain a blocker. Even Amazon carved out third-party software that was too deeply coupled to Oracle to migrate. Enterprises should audit ISV and packaged application Oracle dependencies before committing to a full-lift migration plan.
- Vendor claims require independent validation. The 60/40/70 percent improvement figures are self-reported by Amazon. Design your own proof-of-concept benchmarks against your actual workloads before using these numbers in business cases.