Migration, Integration, and Data Movement Between Clouds
Migration paths
Assess version, edition, features, size, dependencies, character set, and licensing before choosing a tool. Oracle Zero Downtime Migration automates physical migrations to Oracle Cloud and Exadata or Autonomous Database targets, using Data Guard or backup and restore depending on the path. Data Pump handles logical moves and schema remaps. GoldenGate provides continuous replication and minimal-downtime cutover. RMAN is for backup-based movement; Data Guard is for standby-based migration. For cross-cloud integration, GoldenGate CDC, Oracle Integration Cloud, Kafka, and API gateways are common.
Data movement rules
- Keep source and target versions compatible; test the full workload, not just row counts.
- Move large data through object storage or transfer services, not the public internet, and account for egress.
- Preserve sequences, identities, grants, and scheduled jobs; validate with reconciliation queries.
- Plan cutover with a freeze window, DNS or connection-string change, and a tested rollback.
- For ongoing integration, use CDC rather than repeated full extracts.
Worked example
A 19c on-premises database moves to Autonomous Database@Azure. The team uses Zero Downtime Migration with Data Guard for a physical migration, then GoldenGate for the final delta to keep downtime under 15 minutes. They compare row counts and checksums, test the app against the new private endpoint, and keep the source open for rollback until two successful business cycles complete.
Traps
Assuming AWS DMS or Azure DMS fully handles Oracle features; ignoring character-set or endian issues; forgetting sequences and grants; underestimating egress; cutting over without rollback; treating backup restore as zero-downtime.