6.2
Table Of Contents
- Migrating vCloud Automation Center 5.2.3 to vRealize Automation 6.2
- Contents
- Migrating from vCloud Automation Center 5.2.3 to vRealize Automation 6.2
- Updated Information
- Understanding vRealize Automation Migration
- Preparing for Migration
- Running the Pre-Migration Task
- Performing Manual Operations After Pre-Migration
- Stop IaaS Services in Target vRealize Automation System
- Back Up the Target vRealize Automation System
- Backing Up the Target vRealize Automation SQL Database
- Disabling Access to the Source System
- Stop IaaS Services in Source vCloud Automation Center 5.2 System
- Replacing the Target vRealize Automation Database with the Source vCloud Automation Center 5.2 Database
- Update Migration Table to Parse Port Value Data
- Running the Migration Task
- Performing Post-Migration Tasks Checklist
- Troubleshooting
- Cleaning Up Migration Tables in Source 5.2 Database
- Database Name Mismatch During Pre-Migration
- User Principals Cannot be Migrated
- Cannot Connect to Model Manager Web Service
- Cannot Connect to Remote Server
- Cannot Create Application Services Reservation
- Model Manager Web Service is Offline
- Pre-Migration Fails with a Load Balancer Timeout Error
- Migration Fails when Port Number is Part of Database Server Address
- Migration Fails with a Wait Operation Timeout Error
- Migration Fails with a RepoUtil Assembly Timeout Error
- Machines Not Visible on Items Page After Migration
- Reservation Not Available After Migration
Any users and groups that you create in the target vRealize Automation system before you start migration
are removed during migration.
Note Users that you create after pre-migration are not migrated and user changes that you make after
starting pre-migration might not be captured. Resources associated to those users might not work as
expected. If you created or modified users after pre-migration, rerun the pre-migration task to capture that
user data. Resources that are associated with users who could not be migrated are assigned to the
default tenant administrator that you specify during pre-migration.
Local machine users are not migrated. Built-in user accounts, such as BUILTIN\Administrator or
BUILTIN\Everyone, are also not migrated. However, for resources that belong to a built-in administrator
account and for which a machine has been provisioned, that machine is migrated and assigned to the
tenant administrator.
Migrating Administrator and User Roles
User roles that were supplied with the source vCloud Automation Center 5.2 system are migrated to the
equivalent role in the target system.
Custom roles are not migrated. You can recreate custom roles in the target system after migration is
finished.
Consider removing unnecessary users and customized roles before migration to simplify reports and
decrease migration time.
Table 1‑2. Source and target Role Mapping
Source vCloud Automation Center 5.2 Role Target vRealize Automation Role
vRealize Automation administrator IaaS administrator
Enterprise administrator Tenant administrator and Fabric administrator (dual role)
N/A System administrator (administrator@vsphere.local)
Provisioning group manager Business group manager
Provisioning group support user Business group support user
Provisioning group user Business group user
Fabric administrator Tenant administrator
Based on user changes that are made in the source system, if you rerun the pre-migration task, user role
data is added, updated, deleted, or unchanged in preparation for migration.
Note The pre-migration task prepares to migrate each fabric administrator in the source system to a
tenant administrator role in the target system. If you remove a fabric administrator user from the source
system and then rerun the pre-migration task, that user is not removed from the target data. Unlike other
role types, when you rerun the pre-migration tasks, tenant administrator users can only be added or
updated in preparation for migration.
Migrating vCloud Automation Center 5.2.3 to vRealize Automation 6.2
VMware, Inc. 12