Migrating Oracle from on-prem to RDS Custom

Posted on by Kate Gawron

Time to go a bit old school today! I’ve not blogged about Oracle and on-prem to cloud migrations in a long time, but that doesn’t mean they are continuing, at pace, in the background. Today we’ll be looking at how to migrate an Oracle database from on-premises or self-hosted in the cloud (on an EC2 or Google Compute) to Amazon RDS Custom for Oracle.

This blog explains how to use RMAN Duplicate and DataGuard to migrate from an on-premises/self-hosted Oracle database to Amazon RDS Custom for Oracle

Migrating an Oracle database from on-premises to Amazon RDS Custom isn’t just a lift-and-shift; it’s about preserving control while gaining cloud flexibility. If you’re dealing with legacy apps, custom configurations, or complex recovery setups, RDS Custom gives you the power of Oracle with the convenience of managed infrastructure.

In this guide, we’ll walk through how to migrate Oracle from on-prem to RDS Custom using DataGuard for replication and RMAN Duplicate to initialize the standby. This method minimizes downtime and ensures data consistency.

Why Use RDS Custom?

RDS Custom is built for scenarios where you need:

  • Access to the OS and file system
  • Support for Oracle features like Data Guard, RMAN, and Transparent Data Encryption (TDE)
  • Compatibility with existing on-prem Oracle configurations

Unlike standard RDS, RDS Custom lets you manage the database environment more like you would on-prem.

Prerequisites

Before starting, make sure you have:

  • An on-prem Oracle DB (12c or later)
  • Amazon RDS Custom for Oracle instance deployed
  • VPC and networking configured to allow connectivity
  • IAM roles and policies set up
  • Oracle Data Guard and RMAN configured on-prem
  • SSH access to RDS Custom host (via EC2 instance if needed)

Step-by-Step Migration Process

1. Install and Configure Oracle on RDS Custom

Use AWS Systems Manager or your EC2 jump box to connect and install any missing components. Configure the Oracle listener and ensure the DB is in ARCHIVELOG mode.

2. Enable Force Logging and Archivelog Mode

On the on-prem source:

ALTER DATABASE FORCE LOGGING;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

3. Create Password File and Enable Remote Login

orapwd file=$ORACLE_HOME/dbs/orapw<ORACLE_SID> password=YourPwd entries=5
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;

4. TNS Configuration

Ensure both source and RDS Custom can resolve each other’s TNS entries. Edit tnsnames.ora and listener.ora accordingly.

Example TNS entry:

RDSCUSTOM =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = rds-hostname)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl)
    )
  )

5. Prepare RDS Custom as Standby

On the RDS Custom instance:

  • Create the same directory structure
  • Set up initialization parameter file (pfile) or spfile
  • Ensure DB_NAME and DB_UNIQUE_NAME are correctly set
  • Use RMAN Duplicate to clone the database as standby
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE
  DORECOVER
  SPFILE
  SET DB_UNIQUE_NAME='rdsstandby'
  SET FAL_SERVER='onprem'
  SET FAL_CLIENT='rdsstandby'
  SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(onprem,rdsstandby)'
  NOFILENAMECHECK;

6. Configure Data Guard

Edit dg_broker_config:

ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(onprem,rdsstandby)';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=rdsstandby ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=rdsstandby';

Start the broker:

DGMGRL> CREATE CONFIGURATION 'DGConfig' AS PRIMARY DATABASE IS 'onprem' CONNECT IDENTIFIER IS 'onprem';
DGMGRL> ADD DATABASE 'rdsstandby' AS CONNECT IDENTIFIER IS 'rdsstandby' MAINTAINED AS PHYSICAL;
DGMGRL> ENABLE CONFIGURATION;

7. Switchover (Optional for Cutover)

Once the standby is in sync and you’re ready for cutover:

DGMGRL> SWITCHOVER TO 'rdsstandby';

This makes RDS Custom the new primary.

Tips and Best Practices

  • Monitor latency: Use v$dataguard_stats to keep an eye on log apply lag.
  • Backups: Ensure RMAN backups are running consistently post-migration.
  • Testing: Always rehearse this in a lower environment before production cutover.
  • Security: Use SSL/TLS for communication between sites.

Conclusion

Using Data Guard and RMAN Duplicate to migrate Oracle from on-prem to RDS Custom gives you a reliable, low-downtime path to the cloud. You keep control of the environment while benefiting from AWS automation and resilience.

This isn’t just a migration. It’s an upgrade in how you manage Oracle infrastructure.

If you need expert advice in moving your critical databases to the cloud, you can get in touch with me here.

Loading

Related Post