7.4
Table Of Contents
- Migrating vRealize Automation to 7.4
- Contents
- Migrating vRealize Automation
- vRealize Automation Environment User Interfaces
- Migration Prerequisites
- Pre-Migration Tasks
- Review Changes Introduced by Migration from vRealize Automation 6.2.x to 7.x
- Apply Software Agent Patch
- Change DoDeletes Setting on the vSphere Agent to False
- Check Templates in Your vRealize Automation 6.x Source Environment
- Prepare vRealize Automation Virtual Machines for Migration
- Gather Information Required for Migration
- Obtain the Encryption Key
- List Tenant and IaaS Administrators
- Add Each Tenant from the Source Environment
- Create an Administrator for Each Added Tenant
- Synchronize Users and Groups Before Migration to a Minimal Environment
- Synchronize Users and Groups Before Migration to a High-Availability Environment
- Run Data Collection in Source
- Manually Clone the Source Microsoft SQL Database
- Snapshot the Target Environment
- Migration Procedures
- Post-Migration Tasks
- Add Tenant and IaaS Administrators
- Run Test Connection and Verify Migrated Endpoints
- Run Data Collection on Target
- Reconfigure Load Balancers After Migration
- Migrate an External Orchestrator Server
- Reconfigure the vRealize Automation Endpoint
- Reconfigure the vRealize Automation Infrastructure Endpoint
- Install vRealize Orchestrator Customization
- Reconfigure Embedded vRealize Orchestrator Endpoint
- Reconfigure the Azure Endpoint
- Migrate Automation Application Services
- Delete Original Target vRealize Automation IaaS Microsoft SQL Database
- Update Data Center Location Menu Contents After Migration
- Upgrading Software Agents to TLS 1.2
- Validate the Target vRealize Automation 7.4 Environment
- Troubleshooting Migration
- PostgreSQL Version Causes Error
- Some Virtual Machines Do Not Have a Deployment Created during Migration
- Migration Log Locations
- Catalog Items Appear in the Service Catalog After Migration But Are Not Available to Request
- Data Collection Radio buttons Disabled in vRealize Automation
- Troubleshooting the Software Agent Upgrade
Migrating vRealize Automation 1
You can perform a side-by-side upgrade of your current vRealize Automation environment using
migration.
Migration moves all data, except for tenants and identity stores, from your current vRealize Automation
source environment to a target deployment of the latest version of vRealize Automation. In addition,
migration moves all data from the embedded vRealize Orchestrator 7.x to the target deployment.
Migration does not change your source environment except to stop vRealize Automation services for the
time required to collect and copy the data safely to your target environment. Depending on the size of the
source vRealize Automation database, migration can take from a few minutes to hours.
You can migrate your source environment to a minimal deployment or a high-availability deployment.
If you plan to put your target environment into production after migration, do not put your source
environment back into service. Changes to your source environment after migration are not synchronized
with your target environment.
If your source environment is integrated with vCloud Air or vCloud Director or has physical endpoints, you
must use migration to perform an upgrade. Migration removes these endpoints and everything associated
with them from the target environment. Migration also removes a 6.x
VMware vRealize Application Services integration from the target environment.
Note You must complete additional tasks to prepare your vRealize Automation virtual machines before
you migrate. Before you migrate, review Knowledge Base article 51531.
If you migrate from vRealize Automation 6.2.x to the latest version, you might experience these issues.
VMware, Inc.
5