Migrating existing workload VMs using Cross vCenter Server vMotion to a new validated SDDC environment can be a quick and effective. After the requirements and connectivity are in place, the migration can happen in a single large migration window or run through on an ad-hoc or on-demand basis.

In this migration option, the existing source and the new SDDC environment co-exist during or after the migration process is complete. According to the requirements, you can keep the old environment online or decommission it for another purpose.

The exact process of workload migration might differ slightly according to the configuration of the existing source environment but using vSphere vMotion is one of the simplest and safest methods for aligning to a VMware Validated Design standard.

Figure 1. Workload SDDC Migration Option

Use Cross vCenter Server vMotion to migrate tenant workloads to an SDDC that is deployed according to the VMware Validated Designs.


You must fulfill the following requirements to establish a cross vCenter Server vMotion migration of the workloads from an existing non-validated SDDC to a new validated SDDC:

  • The source and destination vCenter Server instances and ESXi hosts must be running version 6.0 or later.

  • The cross vCenter Server and long distance vMotion features require an Enterprise Plus license.

  • When using the vSphere Web Client, both vCenter Server instances must be in Enhanced Linked Mode and must be in the same vCenter Single Sign-On domain so that the source vCenter Server can authenticate to the destination vCenter Server.

  • Both vCenter Server instances must be time-synchronized with each other for correct vCenter Single Sign-On token verification.

  • For migration of compute resources only, both vCenter Server instances must be connected to the shared virtual machine storage.

  • vSphere APIs/CLI is needed if both vCenter Server instances exist in separate vSphere Single Sign-On domains.

After the new environment is configured, you must provide the following configuration for workload migration:

  • Establish network connectivity between source and destination hosts.

  • Temporarily configure NSX Layer 2 bridging for workload subnets or reassign IP addresses of the workload VMs as a part of the migration process.

  • Build or assign an existing virtual machine to run the migration scripts. This virtual machine must communicate with the vCenter Server and Single Sign-On instances in both the source and destination environments.

  • Use test VMs to ensure end-to-end technical and process coverage.

Duration and Maintenance Windows

Before you migrate the workloads to the new validated SDDC environment, conduct a Migration Candidate Assessment to verify that all information is known and migrations can be timed and scheduled as appropriate.

Understanding the migration time lines is critical for planning and scheduling. Careful analysis of the Migration Candidate Assessment for the workloads that need to be migrated must take place before to any migration starts.

By using Cross vCenter Server vMotion, the downtime when migrating workloads can be zero. However, according to the details that you discovered during workload analysis, shutting the workload down prior to the migration could be a better option. For example, shut down the workload in the following cases:

  • High average I/O activity on the workload

  • Workload that is a part of a multi-machine application whose VMs must reside in the same environment

Perform test migrations before the actual workload migration to capture performance metrics about the environmental capabilities. Test large and small VM configuration sizes and use these metrics to estimate each workload migration. Advise application and VM owners of the expected migration time.


To reduce the risks when performing changes in an environment, perform the following activities:

  1. Perform the Migration Candidate Assessment. See Migration Candidate Assessment.

    This process ensures that the source and destination environments, and the migration candidate details as known and documented.

  2. Input the details from Migration Candidate Assessment in the Migration Schedule which in turn drives the entire repeatable process for migrations.

Consider the following best practices to avoid common mistakes during migration:

  • Avoid splitting application VMs in different migration groups. Keep VMs that host a single application in the same migration group.

  • Ensure that the appropriate networks are available in both locations.

  • Document and duplicate any existing reservations or limits to ensure VMs perform the same post-migration.

  • Ensure that management authentication and authorization models are identical in both locations.

  • Test and document the network bandwidth and latency between the source and destination.

  • Consider workload-specific external dependencies such as Active Directory, external databases or physical load-balancers.

Metadata Considerations

When you migrate virtual machines between vCenter Server systems using this option only a limited set of metadata is transferred with each VM. The metadata that is not migrated includes but is not limited to the following:

  • Performance metrics

  • Events

  • Alarms

  • Tags

  • Backup jobs

  • Shares and limits

  • Business group association

  • Permissions

  • All infrastructure logs but the in-guest logs

Backup and Rollback

Before any migration work can commence, implement a backup and restore mechanism for all management components and workload VMs. Test the restore capabilities of these backups to ensure data integrity.

vSphere vMotion does not complete until it verifies a successfully working end state. If a vSphere vMotion operation fails, the source is always left intact, and you can resume the operation of the workloads without loss of data. If a situation occurs where something fails to work or to perform as expected, because vSphere vMotion is bidirectional, you can migrate the workload VMs back to their original source environment to ensure that up-time is retained and fault detection started.


As you migrate workload VMs from the old environment to the new validated SDDC, hosts will be less utilized until unutilized at some stage during the process. Prepare a migration schedule that allows rebalancing of host clusters and expedited removal of hosts.

  • If the hosts are still serviceable, you can rebuild the hosts and join them to the new validated SDDC environment at a steady pace so that you can use the available capacity for incoming migrated workloads. Plan the capacity and expansion of the new validated SDDC environment according to the migration schedule and workload sizing.

  • If the hosts within the old environment are no longer serviceable, perform environment-specific steps for a correct decommissioning process.

After all hosts are evacuated, perform a final backup of all the management VMs before you power them off. After the management VMs are powered off, all management hosts can be either reused or decommissioned in the same way as the compute hosts.