When you migrate to vRealize Operations Manager, certain best practices help to ensure that the data import process succeeds. Without them, the migration might appear to succeed, but the new deployment might not be fully monitoring the inventory or providing all of the data that you expect.

Do not migrate a source when the target is already monitoring the same inventory. For example, if your earlier deployment is monitoring your vCenter instance, but the new deployment is already monitoring the same vCenter instance, the combining of the earlier data with the new data is not supported.

Similarly, even a single virtual machine, if discovered by different adapters (for example by vCenter on the source and by VIM on the target) cannot have its earlier data imported, because that virtual machine was already being monitored by the target.

Before you start the migration, make sure that the source and target are configured to the same system time. Be aware that changing the setting might make the system time different than the real time, and time dependent features such as maintenance schedules might run at unexpected times.

Before you start the migration, make sure that adapters that were installed for the source are installed at the target. The migration does not import data for which there is no adapter.

Before you start the import, make sure that the target deployment is not licensed at a lower level than the source. For example, a target that runs a standard license may not monitor the same source inventory that is possible with a source that includes an enterprise license. To ensure no loss in coverage, the target license must be equal to or greater than the source license.

Before you start the import, on the target, verify the data retention settings under the Administration option, in Global Settings. The data retention settings are not migrated, and the defaults might be shorter than what was configured on the source.

When a target data retention setting is shorter than the source, the next cleanup cycle on the target removes migrated historical data that falls outside the target retention time setting.

Before you start the import, on the source, disable dynamic thresholding (DT). DT is CPU intensive and will slow and possibly even stop the import process.

While an import is in progress, do not make changes to the source inventory or resources.

Migration is resource intensive at the source. For improved performance, consider doubling the memory of the source deployment before beginning the migration. In addition, restart the source before beginning the migration.

After migration, you may return the source to its earlier size.


No rollback option is available after you perform a migration.

Before you start the import, back up the target vRealize Operations Manager cluster.

It is assumed that your site uses a commercial backup product such as NetBackup in conjunction with vStorage APIs for Data Protection (VADP). Configuration details for third-party backup applications go beyond the scope of this document, but many resources are available.

When online, a vCenter Operations Manager cluster is very dynamic. Data is always being updated and modified, and it might be impossible to get a real-time snapshot.

If you restore a vRealize Operations Manager cluster, it takes a few collection cycles for connections to re-establish themselves and to get to a true picture of the current state of the environment.

A restore operation must be full, not partial, and must restore the entire cluster, not individual nodes. Partial or individual restores are not supported.

Backing up, and being able to restore, is always a recommended practice in case a migration fails to produce the result that you want.