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
n
SCCM.Server.UserName
n
Sysprep.Identification.DomainAdmin
n
Users.%.AddUser
After migration is finished, update custom properties that include WinPE or Linux ISOs to include any new
ISO information, such as location or name. See Recreating ISOs and Templates That Contain a Guest
Agent.
For information about these and other custom properties, see Custom Properties Reference in the
vRealize Automation documentation.
Migrating to One Target System and Then to Another
You can initially migrate your supported vRealize Automation source data to a supported target system,
and later migrate that same source data to another target system, but you must use a specific procedure
to do so successfully. For example you might want to migrate to a test system and then migrate to a
production system. or you might also want to migrate in a Beta environment and then migrate in a
released environment.
When you migrate, the migration tool creates several table entries in the source database. These tables
remain after the migration process is finished. If you choose to later migrate to a different target system
than the system that you originally specified, for example first to a test system and later to a production
system, you must first delete these stale migration tables from the source database. If you created a
backup of the source database before you started the migration process, you can alternatively restore
that database.
To migrate to a different target system, you must first delete the migration tables from the source
database and then start the pre-migration and migration process from the beginning. For information
about deleting the stale migration tables from the source database, see Cleaning Up Migration Tables in
Source 5.2 Database.
Problems with migration tables in the source database occur most commonly for the following reasons:
n
You specify one target system when you run pre-migration and a different one when you rerun pre-
migration.
n
You specify one target system when you run pre-migration and a different one when you run
migration.
n
You specify a test target system when you initially run pre-migration and migration and a production
target system when you rerun pre-migration and migration.
n
You specify a beta target system when initially run pre-migration and migration and a production
target system when you rerun pre-migration and migration.
If you migrate to one target system and later migrate to a different target system, managed machines may
not be visible in the catalog items page when migration is finished. This occurs if stale migration tables
are present in the source database when you migrate to a different target system. For details, see
Machines Not Visible on Items Page After Migration.
Migrating vCloud Automation Center 5.2.3 to vRealize Automation 6.2
VMware, Inc. 19