7 Performing Migration Using the Instant Deploy Feature

ZDM introduces migration using the instant deploy feature. The instant deploy feature mode in ZDM simplifies the migration of database from on-premises to OCI or EXADATA systems by skipping the need for dedicated compute for ZDM service.

The instant deploy feature has the following features:
  • The Instant Deploy is a lightweight, downloadable software package that lets you run Zero Downtime Migration (ZDM) directly, without having to install or maintain a separate ZDM server.

  • You use the same zdmcli commands and user experience as standard ZDM, however without installing or starting a persistent service.

  • The CLI launches the migration and provides live progress updates.

  • You can run the ZDM instant deploy tool in the same database host that is being migrated.
  • The instant deploy feature enables Oracle to facilitate database migrations for you with minimal infrastructure requirements.
Key benefits
  • No ZDM server setup: download and run; no separate service to install or maintain.
  • Familiar CLI: use the same zdmcli commands you already know.
  • Run where it is convenient: on the ZDM host, on the source DB node, or on the non-ADB target DB node.
  • Flexible data movement: Direct, OCI Object Storage, or NFS.
  • Minimal infrastructure: suitable for constrained or single-host scenarios.
Before you start
  • Permissions: You need OS-level access and, when applicable, sudo privileges on source/target nodes.
  • Connectivity: Ensure network connectivity between nodes (for remote execution) and required firewall rules/ports. - SSH: If running across nodes, ensure SSH trust or provide SSH user/keyoptions.
  • Storage: - Object Storage: Have bucket name and tenancy URL, and a user with permissions to upload/download.
  • NFS: Have a shared path accessible from source and target.
  • Direct: Ensure connectivity and bandwidth for direct transfer.
  • Space: Ensure adequate free space for backups/dumps and logs on involved hosts.
Install and update
  • Instant Deploy is ready to use after download; no installation step is required.
  • To update the kit in instant deploy mode: ./zdminstall.sh update oraclehome=<zdm_home> ziploc=<path_to_zdm_zip>-serverless
Check the mode

To confirm you are in instant deploy mode:

zdmservice status

Note:

The start or stop commands are not applicable in instant deploy mode.

Logical migrations

  • Run with a response file (required). Non-response workflow is not supported for logical migrations.
  • You can run the command on the ZDM host, the source DB node, or the non-ADB target DB node.

Basic command

zdmcli migrate database -rsp /path/to/logical_migration.rsp

Note:

  • If you run on the source node and want to run CPAT locally, set RUNCPATREMOTELY=TRUE in the response file or use -skipadvisor on the command.

  • For Object Storage, ensure the side that needs to transfer files (source for uploads, target for downloads) has an appropriate method configured in the response file. If not configured, ZDM provides a manual upload link when needed.
Examples

Target is Autonomous Database (ADB), run from any allowed node:

zdmcli migrate database -rsp/home/opc/logical_migration.rsp

Target is non-ADB, run from source node with SSH to target:

zdmcli migrate database-rsp /home/opc/logical_migration.rsp -targetnode <target_node_ip>
-tgtauth zdmauth 
-tgtarg1 user:<user> 
-tgtarg2identity_file:/home/<user>/.ssh/id_rsa 
-tgtarg3
sudo_location:/usr/bin/sudo

Target is non-ADB, run from source node without SSH (local operations only on the source; target retrieves from Object Storage or shared storage as configured):

zdmcli migrate database -rsp /home/opc/logical_migration.rsp
Target is non-ADB; run from the target node with SSH access to the source:
./zdmcli migrate database 
-rsp /home/opc/logical_migration.rsp 
-sourcenode <source_node_ip> 
-srcauth zdmauth 
-srcarg1 user:<user> 
-srcarg2 identity_file:/home/<user>/.ssh/id_rsa 
-srcarg3 sudo_location:/usr/bin/sudo
Target is non-ADB; run from the target node without SSH access to the source (local operations only on the target; source uploads dump files to Object Storage as configured in the response file):
./zdmcli migrate database -rsp /home/opc/logical_migration.rsp

Physical migrations

  • Response file is optional for physical migrations. If you omit -rsp, specify the key parameters inline.

    [-migrationmethod] : Specifies the migration method. Values can be OFFLINE_PHYSICAL or ONLINE_PHYSICAL.

    [-targetdb] : Target database name, mandatory parameter if the response file is not used.

    If -migrationmethod is not specified, ONLINE PHYSICAL migration method is chosen by default.

    OSS (Object Storage Service):

    -backupuser: Username for OSS backup.

    -ossbucket: Name of the OSS bucket.

    -ossurl: URL of the OSS host.

    NFS (Network File System):

    -backuppath: Shared NFS path between the source and target databases.

  • If you run on a node that is also participating in the migration (source or target), ZDM handles local execution automatically; you do not need to specify special plugins for local nodes.
  • For remote nodes, provide SSH details using -sourcenode/-targetnode withuser/key/sudo args.

    Note:

    If you want to modify the default RSP details, there are template response files, located at the <zdmkit_dir>/template/<version> directory.

Select a data transfer method

  1. Direct (no extra parameters required apart from the basic ones)
    zdmcli migrate database -sourcedb <src_db_name> -targetdb <tgt_db_name> -targetnode
      <target_node_ip>
  2. Object Storage
    zdmcli migrate database -sourcedb <src_db_name> -targetdb <tgt_db_name> -targetnode <target_node_ip> -backupuser<obj_storage_user> -ossbucket <bucket_name> -ossurl https://objectstorage.<region>.oraclecloud.com
  3. NFS
    zdmcli migrate database -sourcedb <src_db_name> -targetdb <tgt_db_name> -targetnode <target_node_ip> -backuppath/mnt/shared/backup

Running locations and SSH options

  • From ZDM host: Works as standard ZDM; physical migration supports both response-file and non-response workflows.
  • From source node:

    With default SSH configured to target:

    zdmcli migrate database -sourcedb <src_db_name> -targetdb <tgt_db_name> -targetnode <target_node_ip>

    With custom SSH:

    zdmcli migrate database 
-sourcedb <src_db_name> 
-targetdb <tgt_db_name> 
-targetnode <target_node_ip> 
-tgtauth zdmauth 
-tgtarg1 user:<user> 
-tgtarg2 identity_file:/path/to/key 
-tgtarg3 
sudo_location:/usr/bin/sudo

Note:

On the source local node, migration can be performed using either a DB user or a non-DB user. The same user will be used to execute local commands on the source database, as well as to establish the remote target connection, unless custom SSH details are provided. If you just want to change the remote target connection user, you can specify it using -tgtuser <target_user> in the command.

The target user must have sudo privileges on the target system to execute commands as the database user and the Grid home user.

  • From non-ADB target node:

    With default SSH configured to source:

    zdmcli migrate database -sourcedb <src_db_name> -targetdb <tgt_db_name> -sourcenode<source_node_ip>

    With custom SSH:
    zdmcli migrate database 
-sourcedb <src_db_name> 
-targetdb <tgt_db_name>-sourcenode <source_node_ip> 
-srcauth zdmauth 
-srcarg1 user:<user> 
-srcarg2 identity_file:/path/to/key 
-srcarg3sudo_location:/usr/bin/sudo

Note:

On the target local node, the migration user must have sudo privileges. You will be responsible for executing local commands on the target database and for connecting to the remote source, unless you specify custom SSH details.
Hybrid migration:

From the ZDM host: This works the same as a standard ZDM migration and supports only the response-file–based workflow. Hybrid migration from the local source or target node is not supported.

Templates and automation

  • The kit includes template response files for both logical and physical migrations. You can copy and modify these templates to suit your environment.
  • For physical migrations, you can also run without a response file by specifying parameters inline.
  • The kit provides pre/post action templates you can populate with your scripts to automate checks or custom steps across migration phases.

Tips and limitations

  • Logical migration requires a response file; physical migration supports non-response workflow.
  • If using Object Storage, ensure the correct side has upload/download configured; otherwise you may be prompted to upload manually.
  • zdmservice start and zdmservice stop are not used in instant deploy mode; use zdmservice status to confirm the mode.