Zero Downtime Migration Architecture Explained: Phases, REST APIs, and Automation

Most teams treat ZDM as a black box: point it at source and target, run the command, wait. Understanding the phase model underneath changes how migrations get planned, monitored, and integrated into larger release pipelines.

Each named phase is independently checkpointed. A DBA can inspect logs after any single phase, pause deliberately before ZDM_SWITCHOVER, and resume only that phase if a transient failure occurred - without re-running discovery or standby build steps that already succeeded.

Each named phase here is independently checkpointed, which is the detail most teams miss when they first read the ZDM documentation. A DBA can inspect the logs for any single phase in isolation, deliberately pause before ZDM_SWITCHOVER to run manual validation, and if something fails partway through standby build, resume from that exact phase instead of restarting source discovery from zero. The phase boundaries are not just documentation structure; they are the actual resumability contract.

This is the same control-host pattern drawn as a formal infrastructure diagram rather than a phase list. Notice the ZDM Service Host sits in its own box, physically and logically separate from both database servers, connected to each only by a dashed SSH line. Neither database ever holds credentials to the other, and the ZDM host itself never holds a direct database connection - only the shell access it needs to invoke RMAN, Data Guard, and Data Pump commands remotely on each side.

Figure 2 · The ZDM Service Host never holds a direct database connection to either side

Beyond the zdmcli command line, ZDM exposes REST endpoints for job submission, status polling, and phase control. This lets migration waves - dozens of databases - be triggered and monitored from an external orchestrator rather than a human running commands database by database.

An orchestrator driving this lifecycle never needs to hold an open connection or block on a long-running call – it submits the job, then polls status on its own schedule, which is exactly the pattern needed to manage dozens of concurrent migrations from a single external system. The pause and resume calls exist specifically so a human reviewer can be inserted into an otherwise fully automated pipeline at exactly the point – right before switchover – where a second pair of eyes matters most.

Figure 2 · The typical REST call sequence for an orchestrated migration wave

This is the piece that turns ZDM from a single-migration tool into a migration factory. The external orchestrator never talks to the source or target databases directly – it only talks to the ZDM Service Host's REST surface, which means the same CI/CD pipeline that triggers one migration can trigger fifty, each tracked by its own job ID, without any additional custom scripting per database.

Figure 4 · ZDM's control host sits at the center of four independent attachment points, never merging them

1. Poll, Don't Block, on Long-Running PhasesStandby build and redo sync can take hours - poll job status via REST rather than holding an open session.
2. Parameterize Response Files per WaveTemplate response files so a migration wave script only needs to substitute source/target identifiers.
3. Centralize Phase LogsShip ZDM logs to a central location for audit, especially across multi-database migration waves.
4. Isolate the ZDM Service Host's Network AccessRestrict SSH access to only the specific source/target pairs it needs for the current wave.