Migrating Oracle Databases to Exadata on AWS: Strategies, Tools & Best Practices

On this page

1. 01 · Why This Migration Is Different, and Why It Isn't
2. 02 · The Migration Topology on AWS
3. 03 · Assess Before You Choose
4. 04 · Choosing the Method and the Tool
5. 05 · Running a Migration With ZDM
6. 06 · Phases From Assessment to Stabilization
7. 07 · Best Practices That Prevent a Bad Weekend
8. 08 · Key Takeaways
9. 09 · Frequently Asked Questions

01 · Why This Migration Is Different, and Why It Isn't

Migration brief · On-premises Oracle to Exadata on AWS

"Do we need AWS DMS, or can we use the Oracle tools we already know?"

Teams moving to Oracle AI Database@AWS (generally available since July 2025 as Oracle Database@AWS) often start by looking at AWS's own migration services. For an Oracle-to-Oracle move onto Exadata, the better tools are Oracle's: Zero Downtime Migration (ZDM), Data Guard, GoldenGate, RMAN, Data Pump and transportable tablespaces. They understand Oracle redo, block formats and metadata, and they are what Oracle designs and tests the Database@AWS targets with.

What is different is the surrounding environment. The target sits in an ODB network in an AWS region, reached from your data center over AWS Direct Connect and from your VPCs through ODB peering. Staging can use Amazon S3 or OCI Object Storage. The DBA team has to work with the network and cloud teams from the first week, because most migration delays come from bandwidth, routing and staging, not from the database.

02 · The Migration Topology on AWS

Answer: A typical migration links the on-premises source to the target Exadata VM cluster in the ODB network over AWS Direct Connect. A ZDM host, usually an EC2 instance, orchestrates the move. Data travels as Data Guard redo, as GoldenGate trails, or as backups staged in Amazon S3 or OCI Object Storage.

The figure below shows all three data paths at once. In a real project you use one or two of them for each database. The top path is physical online migration: ZDM builds a Data Guard standby on Exadata from a backup or directly over the network, then keeps it in sync with redo until switchover. The middle path is backup and restore through a staging bucket, used for offline physical moves and for Data Pump dumps. The bottom path is logical online migration with GoldenGate.

The purple dashed arrows are continuous replication: they keep the target in step with the source until cutover, which is what makes downtime short. The black arrows are one-shot copies. Every path crosses Direct Connect, so its bandwidth sets the floor for both the initial copy and how far replication can fall behind at peak load.

03 · Assess Before You Choose

Answer: Assessment answers four questions per database: how big and busy it is, which version and platform it runs on, how much downtime the business accepts, and what depends on it. Those answers decide the method, the target size and the order of waves.

Start with an inventory that the DBA team trusts. For each database collect the version and patch level, platform and endianness, size including redo generation rate, character set, features in use (partitioning, Advanced Compression, TDE), and the applications and interfaces that connect to it. AWR reports from peak periods give you CPU, IOPS and throughput for sizing the Exadata VM cluster in ECPUs or OCPUs.

Then group databases into waves. Early waves should be small, low-risk and representative: one database per method you plan to use. Complex, highly connected systems such as ERP go later, once the team has measured real transfer rates and run at least one cutover.

The Cloud Premigration Advisor Tool (CPAT) and ZDM's own evaluation mode both flag blockers early, such as unsupported objects for a logical move or missing prerequisites on the source.

04 · Choosing the Method and the Tool

Answer: If the source is little-endian and can keep its version, use ZDM physical online migration with Data Guard for minimal downtime, or physical offline with RMAN when hours of downtime are acceptable. Use ZDM logical migration with Data Pump and GoldenGate when you must change version, platform or structure. For large big-endian databases, consider XTTS with incremental backups.

The decision tree below starts from the platform question, because endianness rules out physical Data Guard migration for AIX, SPARC and HP-UX sources. From there it is mostly a trade between downtime and change: physical methods give the shortest outage with the least validation, logical methods let you upgrade or reorganise in the same move.

Read the leaf boxes as defaults, not rules. A small database with a generous window may be simplest with a plain Data Pump export, even if it qualifies for Data Guard. A database that must also move from non-CDB to a pluggable database can still go physical, with a conversion step after the move, if your ZDM release supports it.

05 · Running a Migration With ZDM

Answer: ZDM runs from a dedicated host and drives the migration through a response file and the zdmcli command. Always run an evaluation first with -eval, pause the job before switchover, and resume it only when the cutover window opens.

ZDM reads its settings from a response file. For a physical online migration the key entries name the method, the target database unique name and how data is transferred. The exact data transfer options available for Oracle AI Database@AWS depend on your ZDM release, so check the release notes and use the template ZDM ships with:

# physical_online.rsp (excerpt)
MIGRATION_METHOD=ONLINE_PHYSICAL
TGT_DB_UNIQUE_NAME=SALES_AWS
PLATFORM_TYPE=EXACS
# DATA_TRANSFER_MEDIUM=OSS      stage the backup in object storage
# DATA_TRANSFER_MEDIUM=DIRECT   restore from service over the network

zdmcli migrate database -rsp /home/zdmuser/physical_online.rsp \
  -sourcedb SALES -sourcenode onprem-db01 -srcauth zdmauth \
  -srcarg1 user:zdmuser -srcarg2 identity_file:/home/zdmuser/.ssh/id_rsa \
  -targetnode exa-aws-node1 -tgtauth zdmauth \
  -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/id_rsa \
  -eval

# real run, stopping once the standby is in sync
zdmcli migrate database ... -pauseafter ZDM_CONFIGURE_DG_SRC
zdmcli query job -jobid 42
zdmcli resume job -jobid 42

The pause is the most useful ZDM habit. It lets you build the standby days in advance, watch transport and apply lag, run validation on a snapshot standby if needed, and then resume into switchover at the agreed time. For logical migrations the same pattern applies with MIGRATION_METHOD=ONLINE_LOGICAL: ZDM runs the Data Pump initial load, starts GoldenGate replication, and pauses before the application switch.

06 · Phases From Assessment to Stabilization

Answer: Run every wave through six phases: assess, plan, pilot, replicate, cutover and stabilize. Each phase ends with an exit gate, such as a signed-off runbook or stable replication lag, and the next phase does not start until that gate is met.

The staircase below shows how the phases overlap in practice. Planning starts before assessment is fully done, and replication runs for days or weeks before cutover. What must not overlap is a phase and its own gate: you do not cut over while lag is unstable, and you do not decommission the source before backups and monitoring are proven on the target.

The yellow pilot bar is the phase teams most want to skip, and the one that most often saves the project. Its exit gate, measured timings and known issues, is what turns the cutover runbook from a plan into a rehearsal.

1. Freeze changes. Stop schema releases and batch changes on the source for the cutover window.
2. Confirm sync. Check Data Guard apply lag or GoldenGate lag is near zero, and validation queries match.
3. Switch over. Resume the ZDM job, or run the Data Guard switchover, and open the target read-write.
4. Repoint applications. Update connect strings or DNS to the target SCAN name and service, then run smoke tests.
5. Keep a way back. Keep the old primary as a standby, or GoldenGate reverse replication, until the go-live is accepted.

07 · Best Practices That Prevent a Bad Weekend

Most of these come from migrations that went wrong somewhere, not from documentation. None is specific to AWS, but each one gets harder to fix once the target is a managed service in another network.

1. Size Direct Connect for the peak redo rate, not the average, and keep migration traffic from starving production replication or backups.
2. Match character sets and time zone files between source and target, or plan the conversion explicitly in a logical move.
3. Bring TDE keys deliberately. Know where the source wallet is, how it moves, and where the master keys live on the target.
4. Upgrade in a separate step for physical moves. Migrate as is, stabilise, then upgrade with AutoUpgrade. Two changes in one weekend double the rollback options you have to test.
5. Gather statistics and compare plans after migration. Exadata features such as Smart Scan change plans; SQL Plan Management baselines from the source help avoid surprises.
6. Set up backups and monitoring before go-live, including the AWS-side integrations your operations team uses, such as Amazon CloudWatch and EventBridge.

A migration is not finished when the database opens on Exadata. It is finished when the first backup restores, the monitoring alerts, and the old system can be switched off.

08 · Key Takeaways

1. Use Oracle's tools for Oracle-to-Oracle moves. ZDM orchestrates Data Guard, GoldenGate, RMAN and Data Pump into Exadata targets on AWS.
2. Platform and downtime decide the method. Little-endian and minutes: physical online. Version change: logical. Big-endian and large: XTTS.
3. Network and staging set the timeline. Direct Connect bandwidth and an S3 or OCI Object Storage staging path need testing in week one.
4. Pause before switchover. Build and sync the target early, then resume the ZDM job only when the window opens.
5. Pilot every method you plan to use. Measured timings make the cutover runbook real.

09 · Frequently Asked Questions