From Amazon RDS Custom for Oracle to what’s next: A technical guide to Oracle migration paths on AWS

This post provides a decision framework and technical guidance to help database administrators and architects navigate the transition facing Amazon Web Services (AWS) customers who run workloads on Amazon Relational Database Service (Amazon RDS) Custom for Oracle. Following the AWS announcement that it will discontinue RDS Custom for Oracle on March 31, 2027, organizations need a clear, practical roadmap to evaluate and execute migration to the best-suited alternative—Amazon RDS for Oracle, Oracle on Amazon Elastic Compute Cloud (Amazon EC2) or Oracle Database@AWS (ODB@AWS)—based on operational, technical, and business requirements.

To get the most out of this guide, readers should be familiar with the following:

• Oracle Database administration fundamentals
• AWS core services, including Amazon RDS, Amazon EC2, Amazon Virtual Private Cloud (Amazon VPC), AWS Identity and Access Management (IAM), and AWS Systems Manager
• Oracle database deployment models on AWS: RDS for Oracle, RDS Custom for Oracle, Amazon EC2 hosted Oracle, and multi-cloud option ODB@AWS
• Basic concepts of Oracle licensing, support timelines, and certified platform requirements

Understanding the change

AWS has announced that RDS Custom for Oracle will reach end of support on March 31, 2027. After this date, customers will no longer be able to access the RDS Custom for Oracle console or resources.

Organizations running workloads on RDS Custom for Oracle should assess their environment now. The key questions to answer are:

• What operating system (OS)-level customizations or dependencies exist on the RDS Custom host?
• What Oracle version, features, parameters, hidden parameters, or patch levels are in use that aren’t available in standard RDS for Oracle?
• What third-party agents or integrations interact with the Oracle OS or file system layer?
• What are the high availability and disaster recovery (HA/DR) requirements and current Oracle Data Guard configurations?
• What are the licensing arrangements: Bring Your Own License (BYOL), Oracle Unlimited License Agreement (ULA), or License Included (LI)?

These answers determine the right migration path. Complex, multi-workload environments should start a phased approach now.

Amazon RDS for Oracle enhancements

RDS for Oracle has gained capabilities that address why customers previously chose RDS Custom for Oracle. The biggest update: maximum storage increased from 64 TiB to 256 TiB, removing the main reason why many customers used RDS Custom for Oracle to hold large databases.

Recent capability improvements

The following improvements make RDS for Oracle a stronger option for workloads that previously required the RDS Custom variant:

• Maximum database storage increased from 64 TiB to up to 256 TiB through additional storage volumes (up to three additional volumes per instance).
• Cross-Region read replicas with additional storage volumes for disaster recovery at scale.
• AWS Organizations upgrade rollout policy for controlled, staggered automatic minor version upgrades across database fleets.
• Oracle Database version support expanded to 26ai. The databases that are currently supported are 19c, 21c, and 26ai Enterprise Edition.

Feature comparison: Amazon RDS for Oracle and Amazon RDS Custom for Oracle

The following table highlights some key capability differences between RDS for Oracle and RDS Custom for Oracle to help teams identify functional gaps and options before migration.

Migration roadmap options

Organizations migrating from RDS Custom for Oracle have three destination options. The best option depends on the workload, OS and business requirements, and target operational model.

The following table compares the three platforms against RDS Custom for Oracle as the current state.

Path 1: Migrate to Amazon RDS for Oracle

RDS for Oracle is the recommended path for managed workloads without OS-level or advanced Oracle infrastructure dependencies. If you chose RDS Custom for Oracle mainly for storage capacity (the old 64 TiB limit), that constraint is gone: RDS for Oracle now supports up to 256 TiB.

RDS for Oracle delivers a comprehensive set of AWS managed capabilities: automated Multi-AZ failover, AWS Backup integration, Amazon CloudWatch metrics, IAM based authentication, automated patching, and version upgrades. This path trades operational flexibility for lower management overhead and higher reliability through AWS automation.

Path 2: Migrate to Oracle on Amazon EC2

Oracle on Amazon EC2 is a strong fit for workloads with OS-level dependencies that can’t be abstracted away: custom batch schedulers, third-party agents, direct file system access, SYSDBA/SYSASM operations beyond the Amazon RDS API surface, or Oracle patches not yet certified on Amazon RDS. Amazon EC2 gives the customer a fully self-managed Oracle environment with control over each layer of the stack.

The trade-off is operational complexity: OS patching, Oracle home maintenance, Oracle Recovery Manager (RMAN) backup management, Oracle Data Guard configuration, and instance lifecycle management become customer responsibilities. Teams on this path should invest in Systems Manager for automation, AWS Backup for Oracle RMAN integration, and CloudWatch custom metrics for observability.

Path 3: Oracle Database@AWS

ODB@AWS is jointly operated by Oracle and AWS, delivering Exadata hardware co-located in AWS data centers with direct, low-latency connectivity to AWS services. It targets organizations that need Exadata-class performance, Oracle RAC, full Oracle infrastructure feature access (Advanced Queuing, Oracle Streams, Oracle Text, Spatial), and continuity of existing Oracle Support agreements and ULAs.

This path suits large-scale Oracle E-Business Suite, PeopleSoft, and Oracle Applications customers who want to consolidate on AWS while keeping RAC and the full Oracle software stack and support model. It offers unified billing through AWS Marketplace, flexible and Oracle Subscription licensing, and network integration with AWS services through the ODB network.

Use cases and migration approaches

The following three use cases represent the most common RDS Custom for Oracle deployment patterns. Each maps to a recommended migration path based on the workload’s technical requirements.

Use case 1: Oracle E-Business Suite to ODB@AWS

In this scenario, a customer runs Oracle E-Business Suite (EBS) 12.2 with Advanced Queuing, Oracle Text, custom PL/SQL jobs, and Oracle Workflow on Exadata, using RAC, Smart Scan, Smart Flash Cache, and dedicated infrastructure to meet performance and security requirements. An active Oracle ULA covers the deployment. A second phase upgrades the database to Oracle 26ai, certified with EBS 12.2 on ODB@AWS.

ODB@AWS is a good fit for the following reasons:

• Oracle EBS 12.2 is certified on ODB@AWS ExaDB-D with Oracle Database 19c—the application tier on Amazon EC2—with full support for Oracle-specific features, including DBMS_SCHEDULER, Advanced Queuing, Oracle Text, and Oracle Spatial.
• Exadata infrastructure co-located in AWS data centers delivers Smart Scan, Smart Flash Cache, and low-latency connectivity to AWS services. This meets transaction-heavy Oracle EBS financial module performance requirements without cross-data center latency.
• Preserves existing licensing and support agreements; SYSDBA access enables EBS patching on Oracle’s certification schedule, not the AWS managed patch timeline.

The migration approach consists of the following key phases:

• Assessment – Capture Automatic Workload Repository (AWR) baselines across Oracle EBS peak windows to right-size the ODB@AWS Exadata VM cluster. Run Oracle EBS Technology Codelevel Checker (ETCC) on the source to find and resolve mandatory patches before migration. Document custom database parameters, Oracle Home patches, and OS agents. Design ODB network CIDR ranges upfront. Initiate Oracle account and Oracle Cloud Infrastructure (OCI) tenancy setup.
• Non-production migration – Provision and peer ODB@AWS to the existing Amazon VPC. Run Oracle EBS pre-clone scripts on source DB and application tiers, then RMAN-duplicate to the ODB@AWS target. Execute post-clone steps, rerun AutoConfig on the Amazon EC2 application tier, start concurrent managers, and re-validate ETCC compliance. Benchmark top concurrent programs and complete full UAT testing before the production migration phase.
• Production migration – Use Oracle Data Guard to continuously synchronize the database from the source RDS Custom (primary) to ODB@AWS (standby). When the apply lag is stable, switch over from primary to standby on ODB@AWS. This yields near-zero downtime (minutes). Rerun AutoConfig on Amazon EC2 application tier nodes, restart Oracle EBS services, and confirm end-to-end validation.

For organizations needing parallel-run validation or phased cutover, Oracle GoldenGate provides bidirectional replication between source and target.

Use case 2: PeopleSoft HCM/Financials to Oracle on Amazon EC2

In this scenario, a customer runs PeopleSoft Human Capital Management and Financials on RDS Custom for Oracle. PeopleSoft HCM requires OS-level cron scheduling, third-party job schedulers, and specific Oracle patch sets for PeopleSoft’s certified platform matrix that RDS for Oracle does not yet support. For PeopleSoft environments that don’t need Oracle RAC or Exadata performance features, Oracle on Amazon EC2 is a good option—it’s flexible and lower cost than ODB@AWS. The database, application, and Process Scheduler tiers all run on Amazon EC2, preserving full OS access, RMAN control, and PeopleTools operational continuity.

Oracle on Amazon EC2 is a good fit for the following reasons:

• PeopleSoft’s Process Scheduler and SQR reporting engine require OS-level integration, file system access, and the ability to spawn processes.
• Batch processing uses shell scripts that must run on the OS alongside the Oracle database.
• Oracle on Amazon EC2 gives full control over Oracle Home, patch level, and database parameters. PeopleSoft’s certified platforms matrix requires specific Oracle Database patches. Third-party tools and agents install directly alongside the Oracle database on the EC2 instance.

The migration approach consists of the following key phases:

• Assessment – Capture AWR baselines to right-size the target EC2 instance and Amazon Elastic Block Store (Amazon EBS) storage. Confirm Oracle PeopleSoft PeopleTools compatibility with Oracle Database 19c. Document custom database parameters, Oracle Home patches, OS agents, and Process Scheduler configuration files from the RDS Custom host. Validate Integration Broker node configuration, external system endpoints, and RMAN backup/recovery procedures to Amazon Simple Storage Service (Amazon S3) on the source environment.
• Non-production validation – Provision a target EC2 DB instance running Oracle 19c, matched to the source Oracle Home and patch level. Perform RMAN backup-based duplication from RDS Custom to Amazon EC2 using Amazon S3. Run post-clone steps on all application tier nodes to point to the new EC2 DB instance, reconfigure Process Scheduler domains, and re-register Integration Broker nodes. Complete end-to-end UAT testing and benchmark against the AWR baseline.
• Production migration – Establish Oracle Data Guard between RDS Custom (primary) and Amazon EC2 (standby) for continuous redo log synchronization ahead of cutover. When the primary and standby are synchronized, an Oracle Data Guard switchover promotes Amazon EC2 to primary in near-zero downtime (minutes). Update all PeopleSoft application tier nodes with new DB instance connection strings, restart services, and confirm end-to-end validation before the maintenance window closes.

Use case 3: Oracle DB with Oracle APEX to Amazon RDS for Oracle

In this scenario, a customer running Oracle APEX on Oracle Database 19c on RDS Custom re-platforms to RDS for Oracle. For APEX workloads with no dependency on OS-level access, SYSDBA, RAC, or custom Oracle Home patches, RDS for Oracle is the ideal migration target—it supports APEX through managed Option Groups, removes operational overhead, and is an AWS managed Oracle service with an active support roadmap. This migration moves the customer to a fully managed service with few application changes.

RDS for Oracle is a good fit for the following reasons:

• AWS managed automated backups, patching, Multi-AZ HA, and Amazon RDS Performance Insights avoid DBA intervention for routine lifecycle tasks.
• Oracle APEX is supported through AWS Option Groups (APEX and APEX-DEV). It is deployable as a runtime or full development environment with the listener hosted on a separate EC2 instance.
• Custom initialization parameters are managed through RDS parameter groups—the team reviews hidden parameters during assessment and any gaps flagged before migration.

The migration approach consists of the following key phases:

• Assessment – Document the source RDS Custom APEX environment: APEX version, workspace list, application export inventory, ORDS version and configuration, custom database parameters, OS-level backup scripts, and any custom APEX_version account configurations. Take APEX application exports for all workspaces and applications using the APEX Export utility as a pre-migration safety net. Design and validate AWS Backup.
• Non-production migration – Provision a new RDS for Oracle 19c instance with APEX and APEX-DEV Option Groups: AWS installs APEX automatically, removing the manual SYSDBA-driven process used on RDS Custom. Migrate APEX application schemas and workspace data using Oracle Data Pump export/import, reconfigure ORDS on the EC2 instance to point to the new RDS endpoint, and run rdsadmin.rdsadmin_run_apex_rest_config to configure RESTful services. Validate all APEX applications end-to-end and confirm AWS Backup, AWS Lambda, and Amazon EventBridge schedules with a successful backup and test restore.
• Production migration – During the maintenance window, set APEX applications to unavailable, take a final Oracle Data Pump export from RDS Custom, import it into the production RDS for Oracle instance, and reconfigure ORDS to the new endpoint. Enable Multi-AZ for automated HA, set APEX applications back to available, and confirm end-to-end validation across all workspaces before the window closes.

Migration approach and tools

The primary decision in choosing your migration approach is between physical and logical migration. Each has distinct trade-offs in downtime, complexity, and suitability by target platform:

• Oracle Data Guard – Maintains a synchronized physical standby on the target Amazon EC2 or ODB@AWS platform during migration. When ready, a planned switchover completes in minutes with near-zero data loss and no extended downtime.
• Oracle GoldenGate – Continuously captures and applies redo log changes between source and target, letting both systems run at the same time for heterogeneous migrations, cross-version upgrades, or extended parallel validation.
• Oracle Data Pump (expdp/impdp) – Exports full or partial schemas to a dump file set—stored on Amazon S3 or transferred directly to the target. This option is suitable for smaller databases or non-production environments where a maintenance window is acceptable.
• AWS DMS – AWS Database Migration Service (AWS DMS) supports Oracle as both source and target. Its change data capture (CDC) engine replicates changes continuously with low latency. It’s suitable for migrations to RDS for Oracle that need schema transformation or an extended replication window.

The following table compares physical and logical migration options.

Conclusion

The March 31, 2027, end of support for RDS Custom for Oracle gives Oracle database teams on AWS a defined window to right-size their deployment model—reducing operational overhead, optimizing costs, and improving availability with modern AWS tooling.

The guiding principle is workload-driven platform selection: workloads without OS-level dependencies belong on RDS for Oracle, which now supports up to 256 TiB with extensive AWS automation integration; workloads with genuine OS requirements belong on Amazon EC2; and Oracle Applications or Exadata-dependent workloads belong on ODB@AWS.

To begin planning your migration, review the Amazon RDS for Oracle User Guide, explore the Oracle Database@AWS User Guide, and connect with your AWS account team to discuss your specific requirements.