When a customer’s on-premises Oracle database became unsupported and struggled with scalability and performance, the decision was made to migrate to AWS. The customer had already chosen AWS as their preferred cloud provider, and Amazon RDS for Oracle offered the managed service capabilities they needed: scalability, high availability, simplified maintenance, and reduced operational overhead.
This case study explores how we successfully migrated a 1TB Oracle OLTP database from on-premises to Amazon RDS for Oracle using AWS Database Migration Service (DMS).
Planning the Migration
The migration strategy involved multiple stages of testing before go-live. We began with smaller datasets to validate connectivity, bandwidth, and throughput. Once these test runs were successful, we performed several full dataset migrations to refine the process.
To minimise downtime at cutover, we pre-migrated static, historical, and archived data. This meant that, during the final migration window, only active transactional data needed to be copied.
The chosen target was Oracle on Amazon RDS. We used AWS DMS exclusively, as schema conversion (AWS SCT) was not required. However, since the application schema lacked primary keys on many tables, change data capture (CDC) was not an option. As a result, we planned for, and executed, a controlled downtime of only a few hours.
Executing the Migration
We provisioned a carefully sized replication instance (today, the new serverless option could have been an alternative) and configured source and target endpoints integrated with AWS Secrets Manager.
The migration process included:
- Preparing the target RDS instance with a metadata Oracle Data Pump import to create structures, stored procedures, and other objects.
- Disabling constraints and triggers before loading.
- Running DMS tasks to copy the data – one task per schema, with separate tasks for historical datasets.
- Re-enabling constraints and triggers after migration.
Challenges Addressed
Character set conversion: The source database was migrated to Unicode. Some column sizes were insufficient for the new encoding, so we identified and modified those tables in advance.
Unsupported data types: A small number of Oracle-specific data types were not supported by DMS. We migrated these using Oracle Data Pump.
Validation: The full data migration took around two hours. Validation was carried out using DMS row counts as well as SQL scripts to confirm data consistency between source and target.
Outcomes
The migration delivered measurable benefits:
- 30% performance improvement post-migration.
- Improved scalability and elasticity with Amazon RDS.
- Reduced operational overhead thanks to automated backups, simplified patching, and easier performance tuning.
- Performance Insights in RDS provided built-in tuning capability, replacing the need for costly Oracle performance packs.
- Monitoring and automation became straightforward with Amazon CloudWatch dashboards and event-based automation hooks.
The customer now benefits from a modern, fully managed database platform that supports their business more efficiently and cost-effectively.
Lessons Learnt & Best Practices
- Test thoroughly: Use phased migrations and test bandwidth, schema compatibility, and data validation well ahead of go-live.
- Collaborate with the business/application team:Identify which data needs to be migrated and which can be pre-migrated or archived.
- Plan for constraints: Be aware of CDC limitations (e.g. missing primary keys) and design downtime windows where required.
- Validate rigorously: Always cross-check DMS validation with independent SQL scripts.
If we were to repeat this today, we would consider AWS DMS Serverless, which removes the need to size and manage the replication instance manually.
Conclusion
By carefully planning and executing this migration, we successfully moved a 1TB Oracle OLTP database from on-premises to Amazon RDS for Oracle with minimal downtime and lasting benefits. The project not only improved performance by 30% but also reduced operational burden, simplified monitoring, and provided a scalable foundation for future growth.
This case study was written by Anna Eriksson, Principal Consultant & Architect at Cloud Elemental. Looking to modernise your own databases or streamline cloud migrations? Read more of our case studies and learn how Cloud Elemental can help your organisation move faster, scale smarter, and stay resilient.
