Oracle Zero Downtime Migration (ZDM): Introduction to Automated Database Migration
Article Overview
This guide covers Oracle Zero Downtime Migration (ZDM) — Oracle's free, automated engine for moving Oracle databases into OCI and multicloud targets with minimal or zero downtime. We break down the three migration methods (Physical, Logical, Hybrid), what shipped in the 26.1 release, platform and version support, and a practical decision framework for DBAs planning their first migration.
📋 Table of Contents
- What is Oracle Zero Downtime Migration?
- ZDM 26.1 — What's New
- The Three Migration Methods
- Head-to-Head Comparison Table
- Physical Migration Deep Dive
- Logical Migration Deep Dive
- Hybrid Migration Deep Dive
- Core Capabilities Across All Methods
- Why This Matters for Apps DBAs
- Decision Matrix & Getting Started
- Summary & Next Steps
1.What is Oracle Zero Downtime Migration?
Oracle Zero Downtime Migration (ZDM) is an end-to-end automation tool that moves Oracle databases into Oracle Cloud Infrastructure and multicloud targets with minimal or zero downtime. Instead of manually orchestrating RMAN, Data Guard, GoldenGate, and Data Pump, ZDM drives all of it through a single CLI (zdmcli), from readiness checks through final switchover.
It's built on Oracle's Maximum Availability Architecture (MAA) — meaning it automates the same Data Guard, GoldenGate, and RMAN technologies Oracle already recommends for production resilience, rather than replacing them with something new.
2.ZDM 26.1 — What's New
Oracle ships ZDM updates frequently. Existing configuration files and workflows continue to work unchanged after upgrading — nothing in 26.1 is a breaking change.
Instant Deploy removes the need for a dedicated ZDM service host entirely — you can download the ZDM kit directly onto the source or target database host and run zdmcli migrate from there.
Instant Deploy
No-install mode — run ZDM directly on the source or target server, skipping the dedicated host entirely.
PDB Cloning workflow
Physical migration via database links for small/mid-size databases — Cold, Hot, or Refreshable cloning.
Windows as a source
Physical migrations can now originate from Windows, alongside Linux, Solaris, and AIX.
ExaDB-XS targets
Migrate to Exascale Infrastructure storage via any physical method — online, offline, OSS, NFS, or restore from service.
OKV keystore support
Migrates Oracle Key Vault external keystore wallets, with separate password handling when OKV and TDE differ.
Multi mount point NFS
Different NFS paths for source and target — useful for cross-data-center migrations with network restrictions.
3.The Three Migration Methods
Oracle delivers ZDM as one CLI, but there are three distinct migration methods underneath. The hardware and data-movement technology differ — what you choose depends on your downtime tolerance, version delta, and platform delta.
Physical Migration
Block-level data movement using RMAN and Data Guard. Comes in online (Data Guard switchover — near-zero downtime) and offline (backup/restore — needs a maintenance window) flavors. Requires source and target to be on the same database release, unless combined with the Physical Migration with Upgrade option.
Logical Migration
Row-level data movement using GoldenGate for change capture and Data Pump for the initial load. This is the method to reach for when source and target differ in version or platform — it upgrades and cross-platform-migrates in the same workflow.
Hybrid Migration
Blends physical instantiation with logical (GoldenGate) synchronization for a controlled cutover window — the option when you need both the speed of a physical copy and the flexibility of logical replication.
4.Head-to-Head Comparison Table
| Dimension | Physical | Logical | Hybrid |
|---|---|---|---|
| Data movement | Block-level (RMAN) | Row-level (GoldenGate) | Both |
| Version upgrade in-flight | Only with Upgrade option | Yes | Yes |
| Cross-platform support | Limited | Yes | Yes |
| Typical downtime | Minutes (online) / window (offline) | Minutes at cutover | Minutes at cutover |
| Underlying technology | RMAN + Data Guard | GoldenGate + Data Pump | RMAN + GoldenGate |
| Setup complexity | Lower | Higher | Highest |
| Best for | Same version/platform moves | Version or platform change | Large DBs needing both speed & control |
5.Physical Migration — Deep Dive
Physical migration is the simplest method to reason about: ZDM either keeps a Data Guard standby in sync at the target and switches over (online), or takes a backup and restores it fresh at the target (offline, similar to cloning).
Online physical migration (Data Guard switchover) typically completes its cutover window in well under 15 minutes. Offline physical migration needs a full maintenance window, since the target has no ongoing sync back to the source once cloned.
Advantages
- Fastest, simplest method when versions match
- Online mode keeps production live via Data Guard until cutover
- Fully automated backup, transfer, and restore
- Well-understood technology (RMAN/Data Guard) most DBAs already trust
Disadvantages
- Requires matching DB version unless using Upgrade option
- Offline mode has no fallback sync — needs a maintenance window
- Less flexible across OS/platform changes than Logical
Same-version, same-platform moves into OCI where you want the fastest possible cutover with the least operational complexity.
6.Logical Migration — Deep Dive
A standard Logical Online migration runs: configure ZDM → configure a GoldenGate Extract → start a Data Pump export → start a Data Pump import → configure a GoldenGate Replicat → monitor replication → switch over → validate, clean up, finalize.
Advantages
- Upgrades the database version in-flight
- Supports cross-platform migrations (different OS families)
- Fine-grained replication control via GoldenGate
Disadvantages
- More moving parts — supplemental logging, trail files, DDL replication caveats
- Longer setup and validation time than Physical
- Requires GoldenGate licensing/service awareness for the migration window
Migrations that also need a version upgrade (e.g. 19c → 26ai) or a platform change, bundled into a single project instead of two separate ones.
7.Hybrid Migration — Deep Dive
Hybrid combines an initial physical instantiation (fast bulk data move) with a logical GoldenGate synchronization window for the final cutover — giving you both speed and a controlled, low-risk switchover.
Advantages
- Combines physical speed with logical cutover control
- Good fit for very large databases where a pure logical load would take too long
Disadvantages
- Highest setup complexity of the three methods
- Requires familiarity with both RMAN/Data Guard and GoldenGate configuration
Large, mission-critical databases where you need the bulk-load speed of physical migration but still want a GoldenGate-controlled cutover window.
8.Core Capabilities Across All Methods
These operational features apply regardless of which migration method you choose, and matter once you move from a pilot database to running migrations at fleet scale.
Job subsystem
Manage migrations across a fleet of databases, not just one at a time.
Job scheduler
Queue a migration to start at a future point in time.
Pause / resume
Fit migrations around maintenance windows.
Suspend / resume
Avoid workload spikes caused by migration activity.
Workflow customization
Hook your own scripts before or after any phase.
Full audit trail
Every custom action and job step is logged.
9.Why This Matters for Apps DBAs
Application-tier migrations — EBS, PeopleSoft, JD Edwards, Fusion — are rarely "just the database." Connection strings, TNS aliases, and SLAs tied to real business processes (payroll, month-end close, order processing) make a big-bang cutover risky.
Live until cutover
Data Guard-based physical migration keeps production live and synchronizing right up to the switchover second.
TNS alias migration
Standby-based moves reduce post-migration connection-string cleanup for the apps team.
In-flight upgrades
Combine "move to the cloud" and "get off an EOL version" into one project instead of two.
10.Decision Matrix & Getting Started
The automation layer is identical no matter which method you pick — the real decision is about downtime tolerance and version/platform delta, not familiarity with any one Oracle technology.
| Scenario | Best Method |
|---|---|
| Same version, same OS, want fastest cutover | Physical Online |
| Small/mid database, quick pilot | Physical with PDB Cloning (Instant Deploy) |
| Need a version upgrade in the same project | Logical, or Physical with Upgrade |
| Changing OS/platform | Logical |
| Very large database needing speed + control | Hybrid |
| No maintenance window available at all | Physical Online or Logical (online) |
- 1. Pick a method — Physical, Logical, or Hybrid, based on the table above.
- 2. Choose deployment mode — dedicated ZDM host, or Instant Deploy directly on source/target.
- 3. Confirm support for your exact source/target combination against current release notes.
- 4. Plan your TDE/keystore strategy — file-based wallet or OKV external keystore.
- 5. Size the transfer medium — NFS, Object Storage, or restore-from-service.
- 6. Build a rollback plan for a failed post-switchover validation.
- 7. Pilot in non-production first — Cold cloning or offline methods are the lowest-risk way in.
11.Summary & Next Steps
✅ Key Takeaways:
- ZDM is free, MAA-built automation for Oracle Database migrations into OCI and multicloud targets.
- Three methods — Physical, Logical, Hybrid — cover same-version moves, version/platform upgrades, and large-scale controlled cutovers respectively.
- 26.1 adds Instant Deploy, PDB Cloning, Windows source support, ExaDB-XS targets, and OKV keystore support.
- Job scheduling, pause/resume, and audit trails make ZDM viable at fleet scale, not just for one-off migrations.
Recommended Next Steps:
- Pick a non-critical database and pilot a Physical Offline migration end-to-end in test.
- Get comfortable with the
zdmcliconfiguration template before production is on the line. - Review the current ZDM Release Notes for your exact source/target support combination.
Comments