# Oracle Exadata Cloud Infrastructure Migration Automation Utility Administrator's Guide

This file contains the text from each Oracle Exadata Cloud Infrastructure Migration Automation Utility Administrator's Guide article landing page, release 24.10.1.0.260803.

# Whats New In Oracle Exadata Cloud Infrastructure Migration Utility

Oracle is constantly adding new capabilities to Oracle Exadata Cloud Infrastructure Migration Utility. This section provides a brief overview of new features as they are released.

## Fetching Resource-Based Exadata Image Version

Release 24.10.1.0.260803, dated August 3, 2026, includes a bug fix that improves fetching of the resource-based Exadata Image Version.

Read More: [Fetching Resource-Based Exadata Image Version](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/whats-new-in-oracle-exadata-cloud-infrastructure-migration-utility/fetching-resource-based-exadata-image-version.html)

## Support for X11MV as Migration Target

Release 24.10.0.0.260729, dated July 29, 2026, adds support for X11MV Exadata Infrastructure as a migration target.

Read More: [Support for X11MV as Migration Target](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/whats-new-in-oracle-exadata-cloud-infrastructure-migration-utility/support-for-x11mv-as-migration-target.html)

## ExaDB-C@C Template Generation Issue

Release 24.9.1.0.260717, dated July 17, 2026, includes a bug fix for an issue affecting ExaDB-C@C template generation.

Read More: [ExaDB-C@C Template Generation Issue](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/whats-new-in-oracle-exadata-cloud-infrastructure-migration-utility/exadb-cc-template-generation-issue.html)

## Relocate PDBs Between Source and Target CDBs

Release 24.9.0.0.260430, dated April 30, 2026, introduces the PDB relocate option, enabling pluggable databases to be created from a source container database and relocated to a target container database.

Read More: [Relocate PDBs Between Source and Target CDBs](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/whats-new-in-oracle-exadata-cloud-infrastructure-migration-utility/relocate-pdbs-between-source-and-target-cdbs.html)

## Collecting Diagnostic Information and Logs

Release 24.8.0.0.260310, dated March 10, 2026, adds the `diag_collect` option for gathering diagnostic information and logs to support troubleshooting, along with a fix for adding or updating SYS/TDE passwords in the wallet file.

Read More: [Collecting Diagnostic Information and Logs](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/whats-new-in-oracle-exadata-cloud-infrastructure-migration-utility/collecting-diagnostic-information-and-logs.html)

## Generate Infrastructure Details Report

Release 24.7.0.0.260223, dated February 23, 2026, adds the `generate_report` option for producing detailed infrastructure reports covering VM clusters and database resources.

Read More: [Generate Infrastructure Details Report](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/whats-new-in-oracle-exadata-cloud-infrastructure-migration-utility/generate-infrastructure-details-report.html)

## Custom Software Image or Higher RU for Standby Creation

Release 24.6.0.0.260209, dated February 9, 2026, enables the use of custom software images or higher Release Updates when creating standby databases, providing greater flexibility in standby configuration.

Read More: [Custom Software Image or Higher RU for Standby Creation](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/whats-new-in-oracle-exadata-cloud-infrastructure-migration-utility/custom-software-image-or-higher-ru-for-standby-creation.html)

## Enhancements to Standby Creation, Authentication, and VM Cluster Migration

Release 24.5.0.0.251209, dated December 9, 2025, enhances standby database management, authentication, and VM cluster migration by allowing additional standbys alongside an existing manual standby, supporting Instance Principal and Resource Principal authentication, and enabling specification of a private DNS zone during VM cluster migration.
Read More: [Enhancements to Standby Creation, Authentication, and VM Cluster Migration](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/whats-new-in-oracle-exadata-cloud-infrastructure-migration-utility/enhancements-to-standby-creation-authentication-and-vm-cluster-migration.html)


# Getting Started with the Migration Utility

The Oracle Exadata Cloud Infrastructure Migration Utility streamlines and automates migrations across Exadata Cloud Infrastructure environments.

The utility simplifies hardware refreshes, shape migrations, and cross-service transitions while ensuring accuracy and complete OCI auditability.

## About the Migration Utility

Oracle Exadata Cloud Infrastructure Migration Utility is a lightweight Linux-based tool that uses OCI APIs to discover source infrastructure configurations, generate and validate migration templates, provision target Exadata infrastructure and VM clusters, and migrate databases and PDBs. It supports ExaDB-D and ExaDB-C@C migrations across supported infrastructure models, including cross-type migrations, hardware refreshes, system retirement, database redistribution, and PDB relocation. Key benefits include pre-execution validation, parallel and selective migrations, no-downtime database migration through Data Guard standby creation and switchover or failover, OCI auditing, and migration monitoring.

Read More: [About the Migration Utility](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/getting-started-with-the-migration-utility/about-the-migration-utility.html)

## Migration Utility Prerequisites

The utility requires OCI authentication through API keys, instance principals, or resource principals, with appropriate users, groups or dynamic groups, matching rules, and IAM policies for database, networking, infrastructure, VM cluster, DNS, work request, and PDB operations; target-compartment permissions are also required when applicable. ExaDB-D and ExaDB-C@C use different infrastructure-management policies. ExaDB-D migrations additionally require suitable VCN capacity, security rules, and source-target VCN connectivity or peering for Data Guard. The client must be a Linux x86-64 machine running Oracle Linux 7, 8, or 9, with sufficient OCI service limits and outbound HTTPS access through port 443.

Read More: [Migration Utility Prerequisites](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/getting-started-with-the-migration-utility/migration-utility-prerequisites.html)

## Prepare to Use the Migration Utility

Preparation involves downloading the latest Linux x86-64 utility patch from My Oracle Support, copying and extracting it on the client as an appropriate user, and configuring proxy variables when required. Set authentication, OCI configuration-file, and profile environment variables when using instance principals, resource principals, custom configuration locations, or nondefault profiles. Before execution, collect the source Exadata Infrastructure OCID, VM Cluster OCID, and, for PDB relocation, the source Database OCID from the OCI Console for the relevant ExaDB-D or ExaDB-C@C resources.
Read More: [Prepare to Use the Migration Utility](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/getting-started-with-the-migration-utility/prepare-to-use-the-migration-utility.html)


# Migration Utility Functionality

Learn about the features and capabilities of Oracle Exadata Cloud Infrastructure Migration Utility.

## Migration Utility Operations

The Oracle Exadata Cloud Infrastructure Migration Utility uses the `exacloudmigration` command to generate reports and input templates, create or migrate Exadata infrastructures, VM clusters, database homes, databases, and PDBs, manage wallets and Data Guard operations, inspect networks and jobs, create databases from backups, and collect diagnostics. Global options provide help and version information, while commands support targeted or comprehensive migration workflows.

Read More: [Migration Utility Operations](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/migration-utility-operations.html)

## Migration Utility Directory Structure

When the utility is extracted under `/home/opc`, generated input templates are stored in `/home/opc/inputs/`, infrastructure and VM cluster templates in infrastructure-specific subdirectories, database and PDB templates beneath each VM cluster directory, and job logs in `/home/opc/exacloudmigration_data/logs/`.

Read More: [Migration Utility Directory Structure](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/migration-utility-directory-structure.html)

## Input Template File Format

Migration input templates contain global parameters and resource-specific parameter sections. Resource sections describe the Exadata infrastructure, individual VM clusters, databases, and each database’s PDBs, enabling the utility to validate and execute creation or migration operations according to the configured values.

Read More: [Input Template File Format](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/input-template-file-format.html)

## Generate Report

The `generate_report` command discovers and documents the configuration of a specified Exadata infrastructure, including infrastructure, VM cluster, server, storage, software, CPU, memory, and database details. Reports can be produced in HTML or JSON format with a selected output filename and OCI profile, supporting migration planning, capacity assessment, image selection, and database distribution decisions.

Read More: [Generate Report](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/generate-report.html)

## Generate Input Templates

The `generate_template` command captures source Exadata configuration details into editable templates for infrastructure, VM clusters, databases, and PDBs. It can generate all templates or only selected resource types, supports ExaDB-D and ExaDB-C@C targets, allows custom filenames and OCI profiles, and uses global and resource-specific parameters to control target creation and migration.

Read More: [Generate Input Templates](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/generate-input-templates.html)

## Generate Patches File

For ExaDB-C@C sources, the `ecmasshutility get_patches` command must be run by the `oracle` user on a source VM cluster database server to create a patches file listing one-off patches and Release Updates applied to each Oracle home. The file must be copied into the appropriate VM cluster input directory for infrastructure, VM cluster, database home image, database home, and Data Guard migration operations, unless the `nopatch` option is used.

Read More: [Generate Patches File](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/generate-patches-file.html)

## Validate and Dry Run

The `--dry-run` option validates generated and modified input templates and performs an OCI dry run without changing either environment. It is recommended for repeated prechecks before create or migrate commands; resource selection can be controlled by template `create=yes|no`, `-a` to include all listed resources, or `-l` to include only specified resources.

Read More: [Validate and Dry Run](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/validate-and-dry-run.html)

## Create Exadata Infrastructure

The `create_infra` command creates Exadata infrastructure in a target region or compartment from a generated infrastructure input file. It supports dry-run validation and, after successful checks, replicates infrastructure settings such as free-form tags, customer contacts, and maintenance windows; infrastructure creation generally takes approximately three to five minutes.

Read More: [Create Exadata Infrastructure](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/create-exadata-infrastructure.html)

## Create VM Clusters

The `create_vmcluster` command creates all or selected VM clusters in an available target infrastructure using a VM cluster template. It supports dry-run validation, comma-delimited cluster selection, parallel creation of multiple clusters, and replication of metadata such as free-form tags and SSH keys; creating one VM cluster can take approximately six hours.

Read More: [Create VM Clusters](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/create-vm-clusters.html)

## Create Database dbHome Software Image

The `create_dbhomeimage` command creates database home software images for all or selected databases on a source VM cluster after validating the database template and target VM cluster. It supports dry runs, target VM cluster selection, and ExaDB-C@C patch files, with `nopatch` available to use the source home’s base Release Update instead of one-off patches.

Read More: [Create Database dbHome Software Image](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/create-database-dbhome-software-image.html)

## Migrate Exadata Infrastructure

The `migrate_infra` command performs an end-to-end infrastructure migration by creating the target Exadata infrastructure, selected or all VM clusters, and associated database homes from infrastructure, VM cluster, and optional database templates. It supports dry runs, resource selection, database inclusion, and ExaDB-C@C patch handling through `yes` or `nopatch`, while replicating associated infrastructure and VM cluster metadata.

Read More: [Migrate Exadata Infrastructure](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/migrate-exadata-infrastructure.html)

## Migrate VM Clusters

The `migrate_vmcluster` command migrates all or selected VM clusters to an available target infrastructure and can include database home migration using per-cluster database templates. It supports dry-run validation, resource selection, ExaDB-C@C patch files or `nopatch`, parallel processing of multiple clusters, and replication of tags, SSH keys, and other VM cluster metadata.

Read More: [Migrate VM Clusters](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/migrate-vm-clusters.html)

## Migrate DBHome(s)

The `migrate_dbhomes` command transfers all or selected database homes from a source VM cluster to a target VM cluster using a database input file. It supports dry-run validation, target VM cluster selection, ExaDB-C@C patch files or `nopatch`, and replication of database home free-form tags.

Read More: [Migrate DBHome(s)](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/migrate-dbhomes.html)

## Database Wallet Operations

Database wallet operations securely store SYS and TDE passwords in a file protected by a wallet password, avoiding repeated credential prompts during database migration, Data Guard transitions, reinstate, and PDB relocation. Wallets can be generated, edited, and inspected with either `exacloudmigration` on the client or `ecmasshutility` on a source database server, with support for adding or updating database entries and listing stored database names.

Read More: [Database Wallet Operations](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/database-wallet-operations.html)

## Migrate Databases

The database migration functions establish Data Guard associations or perform switchover and failover between source and target databases. They support all or selected databases, wallet credentials, dry runs, and ExaDB-C@C patch files; cross-model ExaDB-C@C to ExaDB-D database migration is unsupported. Switchover promotes the standby and demotes the primary, while failover promotes the standby and leaves the former primary disabled, with backup settings replicated when applicable.

Read More: [Migrate Databases](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/migrate-databases.html)

## Reinstate Standby

The `reinstate` command restores a disabled standby database to standby status for all or selected databases in a VM cluster. It uses the database input template and optionally a wallet, supports dry-run validation, and prompts for SYS credentials when wallet entries are unavailable.

Read More: [Reinstate Standby](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/reinstate-standby.html)

## Delete Standby

The `delete_standby` command permanently deletes specified standby databases using the database input template and a required comma-delimited database list. It supports dry-run validation and requires confirmation of the databases targeted for termination before deletion.

Read More: [Delete Standby](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/delete-standby.html)

## Migrate PDBs

The `pdb` command relocates or clones all or selected PDBs between source and target CDBs using a PDB input template, optional wallet, and dry-run validation. Relocation drops the source PDB after completion, while cloning supports local, remote, and refresh modes with credential requirements varying by clone type; KMS-managed encryption removes the need for a TDE password.

Read More: [Migrate PDBs](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/migrate-pdbs.html)

## List All Data Guard Associations for Given VM Cluster

The `list_dg_associations` command displays Data Guard associations for all or selected databases in a specified VM cluster. It can obtain the source VM cluster from a database input file or OCID and supports OCI profile selection for ExaDB-D and ExaDB-C@C environments.

Read More: [List All Data Guard Associations for Given VM Cluster](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/list-all-data-guard-associations-for-given-vm-cluster.html)

## List VM Cluster Networks

The `list_vm_networks` command, applicable only to ExaDB-C@C, lists all VM cluster networks associated with a specified Exadata infrastructure. It requires the infrastructure OCID and optionally accepts an OCI profile.

Read More: [List VM Cluster Networks](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/list-vm-cluster-networks.html)

## List the Jobs History

The `list_jobs` command displays recent migration utility job history, showing the number of latest jobs specified by the `--count` option; five jobs are displayed by default.

Read More: [List the Jobs History](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/list-the-jobs-history.html)

## Get Job Details and Status

The `get_job_status` command displays details and status for a utility job identified by job ID. If no ID is supplied, it reports the latest job, and an OCI profile can optionally be specified.

Read More: [Get Job Details and Status](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/get-job-details-and-status.html)

## Create Database from Existing Database Backup

The `create_db_frombackup` command, available only for ExaDB-D, creates all or selected databases from existing database backups using a database input template, optional wallet, and dry-run validation. All PDBs are restored, and credential requirements depend on whether the source uses customer-managed or Oracle-managed keys; wallet entries must exist for the required databases.

Read More: [Create Database from Existing Database Backup](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/create-database-from-existing-database-backup.html)

## Collect Diagnostic Information and Logs

The `diag_collect` command packages utility version information, job details, logs, and input templates into a diagnostic ZIP archive for troubleshooting. It can use a specified output path and filename or create a default diagnostics archive when no destination is provided.
Read More: [Collect Diagnostic Information and Logs](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/migration-utility-functionality/collect-diagnostic-information-and-logs.html)


# Post Migration

Update the connect string with the new SCAN name so that applications and clients can connect to the migrated databases. If SSL/TLS connections are used, update the client wallets accordingly.

If `sqlnet.ora` and `tnsnames.ora` contain any customizations, compare the contents on the primary and standby systems, and update the standby files accordingly.


# Logging And Troubleshooting

Learn how to access logs and troubleshoot issues with Oracle Exadata Cloud Infrastructure Migration Utility.

## Oracle Exadata Cloud Infrastructure Migration Utility Logs

The migration utility automatically creates logs for each job under `/home/opc/exacloudmigration_data/logs` when extracted to `/home/opc`. The main log records the steps performed for an operation, while the debug log contains detailed Java SDK call information for developer-level troubleshooting; filenames include the job ID, such as `job_1_main.log` and `job_1_debug.log`.

Read More: [Oracle Exadata Cloud Infrastructure Migration Utility Logs](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/logging-and-troubleshooting/oracle-exadata-cloud-infrastructure-migration-utility-logs.html)

## Review The Logs

For migration issues, first check the job status with `exacloudmigration get_job_status -i <job number>`, then review the corresponding `job_<jobid>_main.log` file. Check the known issues documentation, locate the Work Request ID in the main log, and review the request in One View. For Data Guard failures involving operations such as `dgassociation`, `switchover`, or `failover`, collect DBaaS diagnostic logs covering one hour before and after the incident, using a comma-separated database list when necessary.

Read More: [Review The Logs](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/logging-and-troubleshooting/review-the-logs.html)

## Upload The Logs To Service Request

If troubleshooting does not resolve the problem, create a Service Request under the Oracle Database service, selecting the migration utility category and the subcategory matching the affected migration type. Use `exacloudmigration diag_collect` to gather a default diagnostic bundle or specify a filename with `-f`; for Data Guard failures, also collect target-cluster DBaaS diagnostics for one hour before and after the issue, including multiple database names as a comma-separated list when required.

Read More: [Upload The Logs To Service Request](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/logging-and-troubleshooting/upload-the-logs-to-service-request.html)

## Troubleshooting And Diagnostics

Additional troubleshooting guidance is available in the Oracle diagnostics-collection and system-troubleshooting documentation for both ExaDB-D and ExaDB-C@C. These resources explain how to collect diagnostic information and investigate issues affecting Exadata Cloud Infrastructure systems and Oracle Exadata Database Service on Cloud@Customer systems.
Read More: [Troubleshooting And Diagnostics](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/logging-and-troubleshooting/troubleshooting-and-diagnostics.html)


# Known Issues

Learn about known issues and their workarounds for Oracle Exadata Cloud Infrastructure Migration Utility.

## Creation Of Data Guard Association Fails

Data Guard association creation fails with DBAAS-70658 when the primary and standby clusters have inconsistent versions of the `dbcs-agent` RPM, and potentially `dbaastools`. Verify installed package versions on every node, then align them across both clusters by updating the agent, admin agent, and `dbaastools` packages using the appropriate `dbaascli` commands and packages obtained from Oracle Support or the cloud operations team.

Read More: [Creation Of Data Guard Association Fails](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/known-issues/creation-of-data-guard-association-fails.html)

## Create Database From Backup Or Data Guard Association Fails

Creating a database from backup or establishing a Data Guard association can fail with DBT-09101 when mandatory target-environment prerequisites are unmet. Review the operation’s `trace.log` file to identify missing requirements, resolve them according to the installation guidance, and retry the operation.

Read More: [Create Database From Backup Or Data Guard Association Fails](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/known-issues/create-database-from-backup-or-data-guard-association-fails.html)

## When To Configure Manual Data Guard

Manual Data Guard configuration is required for migrations between ExaDB-D and ExaDB-C@C because the utility does not support enabling Data Guard, switchover, or failover across these different service types. Customers can duplicate the source database with `dbaascli database duplicate` and configure Data Guard Broker manually, or use Zero Downtime Migration to automate the process.

Read More: [When To Configure Manual Data Guard](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/known-issues/when-to-configure-manual-data-guard.html)

## Does The Utility Support Cross-Tenancy Migration

The utility supports cross-tenancy migration of infrastructure, VM clusters, and database homes; however, Oracle Exadata Database Service currently does not support Data Guard associations between source and target databases during cross-tenancy migrations.

Read More: [Does The Utility Support Cross-Tenancy Migration](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/known-issues/does-the-utility-support-cross-tenancy-migration.html)

## Cluster Verification Failures Due To Hostname Resolution Issues

Cluster verification can fail for ASM integrity, node connectivity, and hosts-file checks when dual IPv4 and IPv6 stacks cause hostnames to resolve inconsistently across nodes, producing PRVG-13632 errors. This known issue is fixed in the 19.26.0.0.250121 Oracle Clusterware Release Update for Grid Infrastructure and RDBMS homes; upgrade to database version 19.26 or later, or, as a less-preferred workaround, disable dual-stack networking on the compute nodes’ admin network before retrying.
Read More: [Cluster Verification Failures Due To Hostname Resolution Issues](https://docs.oracle.com/en/engineered-systems/migration/migration-utility/ecimu/known-issues/cluster-verification-failures-due-to-hostname-resolution-issues.html)