Review the migration overview and prerequisites before you start the migration process.
The Changes from vCloud Automation Center 5.2 and Foundations and Concepts documentation helps administrators better understand the new vRealize Automation functions and behaviors. The Changes from vCloud Automation Center 5.2 PDF is available online in the 6.0 documentation.
Migration to vRealize Automation 6.2 requires that the source system be at vCloud Automation Center 5.2.3 and the target system be at vRealize Automation 6.2 or a later 6.2.x version.
All instances of vCloud Automation Center 5.2, in reference to migration to vRealize Automation 6.2 represent vCloud Automation Center 5.2.3.
The following prerequisites are required for migration.
Install, configure, and license the target vRealize Automation system.
You must have a clean vRealize Automation target system installed and configured in support of migration.
Establish domain trust between the source and target systems.
Configure the target identity store and default vsphere.local tenant for Native Active Directory.
Assign one or more identity store users to be default tenant administrators.
Ensure that the DEM and agent names that you provide during installation match the DEM and agent names used in the source system.
For information about installing, configuring, and licensing the target vRealize Automation system in preparation for migration, see Migrating vRealize Automation in Installation and Configuration in the vRealize Automation documentation.
If you are using an earlier version of vCloud Automation Center 5.2, you must upgrade to vCloud Automation Center 5.2.3 before you can migrate to vRealize Automation 6.2. If you are using vCloud Automation Center 5.2.1 or 5.2.2, you can migrate to 6.1 and then upgrade to vRealize Automation 6.2 or a later 6.2.x version.
Verify that the target vRealize Automation system Model Manager Web Service component is installed and meets the Java requirements listed in IaaS (Windows Server) Requirements in Installation and Configuration.
The Model Manager Web Service administrator requires either the same credentials as the source vRealize Automation system service accounts or else identical privileges to the domains as the source system service accounts.
As documented in the Installation and Configuration section that describes how to configure for migrating vRealize Automation, the Identity Appliance and Windows IaaS servers must be joined to the same domain as the source vRealize Automation system servers or to a domain with identical domain trusts to the source system servers.
See Configure the Identity Appliance in Installation and Configuration.
Verify that the target identity store is configured for Native Active Directory in the target vRealize Automation default tenant, vsphere.local.
See Configure a Native Active Directory Identity Store in Installation and Configuration.
Verify that the HTTPS protocol is configured for the source and target Model Manager Web Services.
Migration requires HTTPS protocol access to the Model Manager Web Service. HTTP is not supported.
Verify that the Model Manager Web Service in the source and target systems remains online during pre-migration and migration.
The Model Manager Web Service runs as part of an Internet Information Server application thread. Once installed, this Web service and the IIS application pool are started by default.
The migration tool checks that these services are online and outputs an error if they are not.
As stated in the migration preparation section of the Installation and Configuration, agent and proxy agent names for the target system must exactly match the names you used in your source system. See Migrating DEM and Agent Information.
If you specify one target system when you initially run pre-migration but subsequently specify a different target system when you rerun pre-migration or when you run migration, migrations fails. The cause of failure is stale migration tables in the source database. If you must specify a different target system than the one you initially specified, delete the stale migration tables before proceeding. See Cleaning Up Migration Tables in Source 5.2 Database.
Verify that Microsoft Distributed Transaction Coordinator (MSDTC) is enabled on all vRealize Automation and associated SQL servers by complying with instructions in VMware Knowledge Base article Various tasks fail after upgrading or migrating to VMware vCloud Automation Center (vCAC) 6.1.x (2089503)Various tasks fail after upgrading or migrating to VMware vCloud Automation Center (vCAC) 6.1.x at http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2089503.
Turn off Storage DRS in all datastore clusters that use Storage DRS.
Switching SDRS Automation to manual mode is not sufficient. Turn Storage DRS on when migration is finished. See Performing Post-Migration Tasks Checklist.
Additional Migration Considerations and Best Practices
Consider the following tips and suggestions.
Consider reducing the number of provisioning groups and special case blueprints before migration to keep the number of migrated entitlements to a minimum. In addition to the two standard entitlements, an entitlement is also created for each blueprint for which restricted access is configured.
Consider removing unnecessary users and customized roles before migration to simplify reports and decrease migration time.
The migration tool requires a secure connection to the source system's Model Manager Web Service server. If you did not install the server with a trusted certificate, such as a domain certificate, a trust error appears during pre-migration when the migration tool attempts to validate the connection. To avoid the error, install the certificate from the source vRealize Automation server in the local trusted certificate store. See Replace a Certificate in the vCloud Automation Center Appliance in Installation and Configuration.