Migrating Oracle to the Cloud: Which Method, and When

Moving an Oracle database to the cloud is a solved problem five times over — Data Pump, transportable
tablespaces, Data Guard, GoldenGate, and ZDM all do it. The hard part isn't the destination; it's
picking the method, because the method — not the cloud — decides your downtime, your risk, and
whether you can roll back when something goes sideways at 2am on cutover night.

There's no single best method. The right one falls out of four questions: how much downtime can you
afford, are you crossing a boundary (endianness, version, platform, character set), how big is
the database, and — the one people forget — what does the target even allow? Answer those and the
method is nearly decided for you. This guide walks the decision for both OCI and Oracle Database@Azure.

The short version. Logical methods (Data Pump, GoldenGate) recreate objects, so they cross
any boundary — version, platform, endianness, character set — but you pay in downtime (Data Pump) or
licensing and complexity (GoldenGate). Physical methods (RMAN/restore, transportable tablespaces,
Data Guard) copy blocks, so they're fast and faithful but locked to the same endianness (and,
for Data Guard, the same version). Data Guard gives near-zero downtime and the best rollback when
the architecture doesn't change; GoldenGate gives near-zero downtime when it does. ZDM is
the free Oracle tool that automates whichever fits. And the target caps your options: Exadata and
Database@Azure allow everything; Autonomous allows logical only.

The two axes that pick your method

Before you compare tools, answer two questions. They eliminate most of the options on their own.

1. How much downtime can you afford? Every method is either an outage (the database is down for
the whole move, and the outage scales with data size) or near-zero (the target is built and synced
while the source keeps serving, and only a brief cutover is downtime). Data Pump and plain RMAN restore
are outages. Data Guard, GoldenGate, and incremental XTTS are near-zero.

2. Are you crossing a boundary? The big one is endianness. Logical methods recreate each block
on load, so they're endian-agnostic — they don't care. Physical methods copy blocks verbatim, so they
require the same endian format on both ends. Check it before you design anything:

SELECT platform_name, endian_format FROM v$transportable_platform ORDER BY endian_format, platform_name;
SELECT platform_name FROM v$transportable_platform
WHERE platform_id = (SELECT platform_id FROM v$database);

The classic cloud migration is getting off a big-endian UNIX box — Solaris SPARC, AIX, HP-UX — and
onto little-endian Linux x86-64 on Exadata or in Azure. That's a cross-endian move, which rules out
a straight RMAN restore or a Data Guard standby entirely. You're left with a logical method, or
transportable tablespaces with an explicit RMAN CONVERT. Version changes and character-set changes
behave the same way: logical handles them, physical mostly doesn't.

Hold those two answers. Now the methods.

The five methods

Method	What it is	Downtime	Crosses endian / version?	Best when
Data Pump (expdp/impdp)	Logical export/import — recreates objects	Proportional to size (full outage)	Yes — any boundary	Small/medium DB, version or charset change, partial move, → Autonomous
Transportable / XTTS	Copy datafiles + Data Pump metadata; XTTS rolls forward with RMAN incrementals	Low (XTTS = just the final read-only increment)	Cross-endian via RMAN CONVERT; cross-version within rules	Very large DB, cross-endian platform exit, want a short cutover
Data Guard (standby → switchover)	Block-identical standby at the target, then switchover	Near-zero (seconds–minutes)	No — same endian and same version	Large DB, same architecture, near-zero downtime + easy rollback
GoldenGate	Logical replication — initial load, then change capture/apply, then cut over	Near-zero (sub-minute)	Yes — version, platform, endian, even heterogeneous	Large DB + minimal downtime and crossing a boundary; need fallback
ZDM	Free Oracle tool that orchestrates the methods above	= whatever method it runs	= whatever method it runs	Migrating to OCI/Exadata/Database@Azure and you want it automated

Data Pump: the universal translator

Logical export/import recreates every object on the target, which is exactly why it crosses version,
platform, endianness, and character set that the physical methods can't. The cost is downtime
proportional to data volume — the unload → reload → rebuild-indexes cycle, not just raw bytes.
PARALLEL and network mode (a direct INSERT … SELECT over a database link, no dump file) help, but
for a large database the outage can still be unacceptable.

One myth to kill: the "source and target can't differ by more than two releases" rule applies only
over a network link — dump-file transfers span a far wider version range. For moving a whole
database there's Full Transportable Export/Import (FTEX), which combines transportable datafiles for
your user data with Data Pump metadata for the rest (source 11.2.0.3+ → target 12c+). And for
Autonomous Database, Data Pump is the answer: stage the dump files in object storage, run as
ADMIN (never SYS), and exclude the objects ADB manages itself — Oracle's canonical recipe is
exclude=cluster,indextype,db_link.

Transportable tablespaces and XTTS: physical, but portable

Transportable tablespaces copy datafiles directly and carry only a small Data Pump metadata export — so
the bulk data is never logically unloaded, which is why it's far faster than Data Pump for large
databases. Same-endian is a plain file copy; cross-endian requires RMAN CONVERT to flip each
block's byte order. Classic TTS needs the tablespaces READ ONLY for the entire copy window — and
that read-only window is your downtime.

XTTS (cross-platform transportable with RMAN incremental backups) is the trick that shrinks it:
take a level-0 backup while the source stays fully online, roll the target copy forward with level-1
incrementals (still online, no downtime), and only the final increment needs the tablespaces read
only — so cutover is near-constant regardless of database size. This is the MAA-recommended way off an
old big-endian UNIX box onto Linux x86-64. It's Enterprise Edition only, and mind the things that don't
transport: TIMESTAMP WITH TIME ZONE columns are skipped (Data Pump warns you) across mismatched time-zone file
versions, TDE column-encrypted tables can't be in a transport set at all, and external tables,
directory objects, and BFILEs aren't in the datafiles — copy and recreate those by hand.

Data Guard: relocate without transforming

When the move doesn't cross a boundary — same endianness, same version, same character set — Data
Guard is the gold standard. Build a physical standby at the target, let Redo Apply catch it up while the
source keeps serving traffic, then switch over. The only downtime is the switchover itself: seconds
to minutes. And it has the best rollback story of any method — after cutover the old primary
automatically becomes a standby of the new one, so if the cloud primary misbehaves you simply switch
back, with no data loss.

The constraints are the flip side of that fidelity: same endian (a physical standby is block-for-block, so cross-endian is out), same DB
version (a switchover is not an upgrade path — upgrading in flight is a separate transient-logical
procedure), Enterprise Edition, and the source in ARCHIVELOG + FORCE LOGGING. This is the
lift-and-shift method: same architecture in, same architecture out, tiny cutover. It runs on the same
switchover/failover machinery covered in The Oracle HA Decision
Tree and detailed in Data Guard Switchover vs
Failover.

GoldenGate: near-zero downtime across any boundary

GoldenGate is logical replication: load the target (typically with Data Pump), then capture changes from
the source's redo and apply them to keep the target in sync, and when replication lag is near zero,
quiesce the app and reconnect it to the target. Cutover is bounded only by drain + reconnect, so a
sub-minute outage is achievable. It's the one method that gives near-zero downtime and crosses every
boundary — version (11g → 26ai in a single move), platform, endianness, even heterogeneous (Oracle ↔
non-Oracle) — with transformation in flight. Bidirectional replication gives you a genuine fallback
after cutover, which is nearly unique among migration methods.

The price is real: GoldenGate is separately licensed (or consumed as the managed OCI GoldenGate
service), it's the most complex method to run (supplemental logging on the source, Extract/Replicat
processes, lag monitoring), and it can't replicate everything — certain materialized views (such as those
created WITH ROWID), some LOB/UDT/spatial types, and tables with no usable row key fall outside it and
get reloaded via Data Pump instead. Reach for it when you need minimal downtime on a
large database that's also crossing a boundary, or when you want that fallback net.

ZDM: the orchestrator, not a sixth method

You rarely wire these up by hand for a real migration. Zero Downtime Migration (ZDM) is Oracle's
free, supported, CLI-driven tool that orchestrates them: it never moves data itself — it drives RMAN,
Data Guard, Data Pump, and GoldenGate for you, wrapped in pre-checks, pause/resume, evaluation dry-runs,
auditing, and fallback. It comes in two families that map exactly onto the physical/logical split:

• Physical online — RMAN + Data Guard standby + switchover. Same platform/endian, Enterprise Edition; near-zero cutover (typically under 15 minutes). ZDM can fold a version upgrade into the same job.
• Logical online — Data Pump initial load + GoldenGate change capture. Crosses boundaries. Minimal downtime.

(Each also has an offline variant that trades the near-zero cutover for not needing GoldenGate or a
standby — and offline physical is the only path for Standard Edition.) If you're migrating to OCI,
Exadata, or Database@Azure, ZDM is how you do it repeatably — especially across a fleet — instead of
hand-scripting. It inherits every constraint of the method underneath, so it doesn't change the
decision; it automates the execution.

The target decides what's even possible

Here's the gate people skip: the method you can use is capped by how much of the target database you
control. Physical methods need SYSDBA, OS/file access, and a database you can mount and recover.
Logical methods need only a SQL connection and a privileged schema. Two of the three common targets give
you a full database; one does not.

• OCI Exadata Database Service & Base Database Service — full Enterprise Edition databases you administer, with SYSDBA and OS access. Everything works: RMAN, physical Data Guard, transportable tablespaces, Data Pump, GoldenGate, and ZDM in both modes. The most flexible target.
• Oracle Database@Azure — the same Exadata Database Service, running on Oracle-managed Exadata hardware physically located inside Azure data centers, on your Azure VNet and billed through Azure. Because it's the same service, you get the same full toolbox, including standing up a physical Data Guard standby straight from on-prem into Azure and switching over — something you can't do into a managed PaaS database. That's the genuine both-clouds differentiator. (Don't confuse it with the older "Oracle Database Service for Azure," which keeps the database in OCI and bridges over the Azure interconnect — a connectivity pattern, not the same target.)
• Autonomous Database (ADB) — fully managed, no SYSDBA, no file access. So physical methods are out entirely: into Autonomous it's logical only — Data Pump (dump files from object storage) or GoldenGate. Its character set defaults to Unicode (AL32UTF8) and can't be changed after provisioning, so a non-Unicode source has to converge to Unicode — run the Cloud Premigration Advisor Tool (CPAT) first.

Rule of thumb: Exadata and Database@Azure = physical + logical; Autonomous = logical only.

The decision, in one tree

Choosing an Oracle cloud migration method. The target and any boundary crossing eliminate options first; downtime tolerance picks between what's left. ZDM automates whichever physical or logical path you land on.

flowchart TD
  A{Target = Autonomous DB?} -- Yes --> B{Downtime budget?}
  B -- Outage OK --> B1[Data Pump<br/>via object storage]
  B -- Near-zero --> B2[GoldenGate<br/>logical online]
  A -- "No — you control the DB<br/>(Exadata / Base DB / Database@Azure)" --> C{Crossing endian<br/>or upgrading version?}
  C -- "Yes (cross-endian / cross-version)" --> D{Downtime budget?}
  D -- Outage OK --> D1[Data Pump or<br/>XTTS + RMAN CONVERT]
  D -- Near-zero --> D2[GoldenGate<br/>logical online]
  C -- "No (same arch)" --> E{Downtime budget?}
  E -- Near-zero --> E1[Data Guard<br/>physical online / ZDM]
  E -- Outage OK --> E2[RMAN restore or<br/>Data Pump]

What teams get wrong

• Picking the destination before the method. The cloud is the easy part; the method is where downtime and risk actually live. Decide how you'll move before you argue about where.
• Assuming Data Guard or RMAN can cross endianness. They can't — block-identical means same endian. A big-endian UNIX box (AIX/Solaris/HP-UX) → Linux x86-64 is a logical or XTTS-with-CONVERT job, never a straight physical restore. Check V$TRANSPORTABLE_PLATFORM first.
• Treating a Data Guard switchover as an upgrade path. Same version required. Upgrading during the move is a different (transient-logical) procedure — don't plan to "just switch over to the new version."
• Forgetting what the target allows. Designing a physical migration into Autonomous, which can't accept one. Confirm the target's capabilities before you design the migration, not after.
• Underestimating GoldenGate. "Near-zero downtime" sounds free; it's separately licensed, the most complex method to operate, and it won't replicate every object. Budget for the license and the labor.
• Sizing downtime as the whole copy. For Data Guard, XTTS, and GoldenGate the copy and sync are online; only the cutover is downtime — minutes, not the hours it takes to move the data.

Want to drill the decision? The cloud-migration method-selection
lab gives you six realistic
scenarios — source platform, version, size, downtime budget, and target (OCI, Database@Azure,
Autonomous) — and you pick the best method and justify it, with a grade.sh self-check. No install
and no cloud account: it trains the judgment, not the keystrokes. (Two scenarios hide a trap real
teams fall into.)

Where this fits

Migration is one piece of running Oracle in the cloud — the rest of the cluster lives in Cloud &
Migration. The near-zero-downtime methods here lean on the same
switchover/failover machinery as The Oracle HA Decision
Tree. And the question that decides where you land
with the full toolbox above — OCI versus Oracle Database@Azure — is its own deep dive, coming next in
this pillar.

FAQ

What is the best way to migrate an Oracle database to the cloud?

There is no single best method — the right one is determined by four things: how much downtime you can afford, whether you are crossing a boundary (endianness, version, platform, or character set), the database size, and what the target allows. Data Pump is simplest but means a full outage; Data Guard gives near-zero downtime when the architecture does not change; GoldenGate gives near-zero downtime when it does; transportable tablespaces (XTTS) move very large databases with a short cutover; and ZDM automates whichever of these fits.

What is the difference between physical and logical Oracle migration?

Physical methods (RMAN restore, transportable tablespaces, Data Guard) copy data blocks verbatim, so they are fast and faithful but require the same endianness on both ends — and, for Data Guard, the same database version. Logical methods (Data Pump, GoldenGate) recreate each object on the target, so they cross version, platform, endianness, and character-set boundaries, at the cost of downtime (Data Pump) or licensing and complexity (GoldenGate).

Can I use Data Guard to migrate across different platforms or versions?

Only within strict limits. A physical standby is block-for-block identical to the primary, so it requires the same endian format and the same database version — a switchover is not an upgrade path. It is ideal for a same-architecture lift-and-shift (for example, on-prem Linux x86-64 to OCI Exadata) with near-zero downtime and easy rollback. If you are crossing endianness or changing version, use a logical method (GoldenGate or Data Pump) or transportable tablespaces with RMAN CONVERT instead.

How do I migrate to Oracle Autonomous Database?

Logical methods only. Autonomous Database is fully managed with no SYSDBA or file-system access, so physical methods (RMAN restore, Data Guard standby, transportable tablespaces) are not possible. Use Data Pump — with dump files staged in object storage, run as ADMIN rather than SYS, excluding objects ADB manages (cluster, indextype, db_link) — for an outage-tolerant move, or GoldenGate for near-zero downtime. Autonomous defaults to the Unicode AL32UTF8 character set, which cannot be changed after provisioning, so run the Cloud Premigration Advisor Tool (CPAT) first if your source is not already Unicode.

What is Oracle Zero Downtime Migration (ZDM)?

ZDM is a free, Oracle-supported tool that orchestrates a migration to OCI, Exadata, or Database@Azure. It does not move data itself — it drives the underlying methods (RMAN, Data Guard, Data Pump, GoldenGate) with pre-checks, pause/resume, and fallback. It has a physical mode (RMAN + Data Guard switchover, for same-endian/same-version moves) and a logical mode (Data Pump + GoldenGate, which crosses boundaries and is the only path into Autonomous). It inherits the constraints of whichever method it runs.

Does GoldenGate give true zero downtime?

Near-zero, not literally zero. The source stays online during the initial load and change replication; the only downtime is the brief window to drain in-flight transactions and reconnect the application to the target, which can be sub-minute. Bidirectional replication can keep the original source current after cutover to enable a fallback. Note that GoldenGate is separately licensed (or consumed as the managed OCI GoldenGate service) and is the most complex method to operate.

How do I migrate Oracle from AIX or Solaris (big-endian) to the cloud?

That is a cross-endian move, because AIX and Solaris SPARC are big-endian while Linux x86-64 (the usual cloud target) is little-endian. A straight RMAN restore or a Data Guard standby will not work across different endianness. Use cross-platform transportable tablespaces (XTTS) with RMAN CONVERT — which uses incremental backups to keep downtime to the final read-only increment — or a logical method (GoldenGate for near-zero downtime, or Data Pump if an outage is acceptable).

Is Oracle Database@Azure different from OCI for migration?

For migration purposes it behaves the same as OCI Exadata Database Service, because that is exactly what it is — Oracle-managed Exadata infrastructure running inside Azure data centers. So the full toolbox applies, including physical Data Guard standby-in and switchover from on-prem straight into Azure. That sets it apart from Autonomous Database (logical methods only) and from the older "Oracle Database Service for Azure," which keeps the database in OCI and connects over the Azure interconnect rather than running Exadata in Azure itself.

Originally published at uptimearchitect.com. I write here in a personal capacity — questions or feedback are welcome via the contact page.