Consolidating vCenter servers: moving hosts, VMs and SSO domains between vCenters

How to consolidate vCenter servers

To consolidate vCenter servers, decide which vCenter stays, then move the workloads under it in one of two ways: move the VMs with cross vCenter vMotion or Advanced Cross vCenter vMotion, or move whole ESXi hosts by removing them from one inventory and adding them to the other. An emptied vCenter is retired once its backups, monitoring and licences have moved. A third operation, the Single Sign-On (SSO) domain repoint in vSphere 8, joins vCenters into one domain without moving any host. In 9.x, Broadcom recommends vCenter linking in VCF Operations instead of Enhanced Linked Mode; it also leaves every inventory where it is.

The method depends on whether the hardware stays, whether vSAN runs and how long VMs may be down.

Broadcom KB 344959, KB 337625, KB 326849 and KB 450887; vSphere 8.0 documentation on Advanced Cross vCenter vMotion and on domain repointing, read on 10 October 2026. The downtime column is our reading of what each source states.

Moving VMs or moving hosts

Moving VMs suits a consolidation that also replaces hardware, with each VM moving while it runs. It needs routed vMotion and provisioning paths between the clusters and target CPUs from the same vendor; the switch from older hosts to new ones is covered in our guide to replacing ESXi hosts. A move that also changes the datastore counts as vMotion without shared storage, which the vSphere 8.0 limits cap at 2 per host at once. Moving hosts suits hardware that stays in service, where only the managing vCenter changes. It needs no copy time but touches distributed switches, HA, DRS and vSAN membership.

As an example, take 40 hosts under three vCenters after two acquisitions: 24 hosts with vSAN under the vCenter that stays, 10 hosts on a SAN under a second vCenter in its own SSO domain, and 6 older hosts under a third. The 10 SAN hosts can move as hosts into a new cluster of the remaining vCenter. The VMs of the 6 older hosts are better moved with Advanced Cross vCenter vMotion into the existing clusters, provided both sides use the same CPU vendor, after which those hosts are retired. The split of the 34 remaining hosts into clusters is covered in our article on vSphere cluster design for 10 to 60 hosts.

Cross vCenter vMotion requirements for a consolidation

Classic cross vCenter vMotion needs both vCenters in Enhanced Linked Mode, which means one SSO domain. Broadcom’s KB 344959 adds that both vCenters “must be time-synchronized with each other”, that source and destination “should be on the same version”, and that the feature requires an Enterprise Plus licence. Through the vSphere APIs, the two vCenters may sit in separate SSO domains.

Advanced Cross vCenter vMotion “does not depend on vCenter Enhanced Linked Mode or Hybrid Linked Mode”, which makes it the tool for vCenters in different domains. Broadcom’s vSphere 8.0 documentation requires the vCenter from which you start the import or export to run 7.0 Update 1c or later, the source vCenter and the destination ESXi hosts 6.7 or later, and the privilege Resource.Query vMotion. Running VMs need a vSphere Enterprise Plus licence on both vCenters; powered-off VMs need vSphere Standard. When you import several VMs in one operation, “the selected virtual machines must be in the same power state”, so plan batches by power state.

KB 344959 also sets two networking limits. Moving a VM from a distributed switch to a standard switch is not supported, and cross vCenter vMotion “is not supported with 3rd party switches”. Create the target port groups on a distributed switch before the first batch. Port details and moves to a provider are in our guide to migrating VMs to a VMware cloud.

Moving ESXi hosts to another vCenter: distributed switch and vSAN

Broadcom’s KB 337625 states that “hosts cannot maintain vDS connectivity during an inventory move”. Its procedure starts with prerequisites: HA is recreated on the new vCenter before the move, “DRS needs to be set to manual or disabled”, and Storage DRS is set to manual with its configuration duplicated at the destination. DRS settings are recreated at the destination too, and the host loses its resource pools. The steps are then:

1. Back up the distributed switch configuration.
2. Create a standard switch on the host for VMs, VMkernel adapters and management traffic, and move the host’s networking to it.
3. Remove the host from the source vCenter cluster.
4. Add the host to the destination vCenter.
5. Create or import the distributed switches on the destination vCenter.
6. Move the host’s networking from the standard switch back to the distributed switch.

If the destination cluster uses EVC, the KB says to “power off all VMs before adding the host”.

A vSAN cluster needs further steps. KB 326849 asks for a target vCenter “with a build version equal to or greater than the version of the ESXi hosts”, a new cluster created “with DRS, and vSphere HA, disabled”, vSAN enabled with the services of the original cluster, the KMS servers under the same names where encryption runs, and storage policies that “match the vSAN policies from the old Cluster”, or vSAN may resync. Before the hosts are disconnected, IgnoreClusterMemberListUpdates is set to 1 so that they keep their unicast configuration. They move one at a time, each added outside the cluster first and then moved into it, with a check of the member count. Adding a host straight into the cluster forces maintenance mode, which “can negatively impact running VMs”. When all hosts are in, the setting goes back to 0. The KB does not support moving a cluster with vSAN File Service and asks for a stretched cluster to be unstretched first.

Our engineering partner Vixen.UNO carries out cross-cluster migrations in agreed maintenance windows, with a rollback plan at every stage. Describe your vCenters, clusters and switch types in the form below, including which clusters run vSAN.

SSO domain repoint in vSphere 8

The repoint moves a vCenter into an existing or a new SSO domain, from vCenter 6.7 Update 1. Broadcom’s vSphere 8.0 documentation requires the target to be “of the same version” and the nodes “of the same version and build number”, and a file-based backup of each node first. The command is cmsso-util domain-repoint, run as root on the appliance in two modes. Pre-check “does not migrate any data, but checks for conflicts” and fetches tags, categories, roles and privileges; for each conflict you choose Copy, Skip or Merge. Execute imports it, and “Services such as tagging and licensing are retained and migrated to the new domain.”

KB 450887 lists what the repoint does not carry. Because “the vmdir structure is recreated”, global permissions, custom local SSO users and groups and identity sources are documented first and recreated afterwards, the directory service join is redone, and external solutions such as NSX are registered again. For vCenters in Enhanced Linked Mode, it asks for “a simultaneous, powered-off (offline) snapshot of all vCenter Server nodes” and repoints the first node, then the others against an already repointed replication partner. The same KB states: “Cross-domain repointing is not supported in VMware Cloud Foundation (VCF) environments.” The backup itself is covered in our guide to vCenter backup and restore.

Enhanced Linked Mode and vCenter linking in 9.x

Broadcom’s VCF 9.0 release notes (vSphere support notes, updated 29 September 2026) state that with vCenter 9.0 Enhanced Linked Mode “is deprecated and will be removed in a future release”. We found no Broadcom document that names that release. The same notes say ELM “is supported in vCenter 9.0 to allow smooth upgrade of existing infrastructure to VCF”, with “the grouping capability under VCF Operations” as the recommended alternative. Broadcom’s KB 436011 for vSphere Foundation 9.x replaces an ELM setup this way: powered-off snapshots of the vCenter VMs, cmsso-util break-elm, the same identity provider on every vCenter, then linking in VCF Operations. It notes that “IDP user permissions are not shared between vCenter systems”, so permissions are set on each vCenter.

Broadcom’s VCF blog of 2 June 2026 says that ELM joins “up to 15 vCenter Server appliances” in one SSO domain, while vCenter linking “removes the requirement for all linked vCenter instances to run the exact same builds”. “The primary prerequisite is vCenter 9.0 or later”, and sign-in runs through VCF SSO with an external OIDC or SAML identity provider. A 9.x consolidation therefore still moves VMs or hosts. Broadcom’s rules for bringing existing vCenters into a VCF instance by converge or import are listed in our comparison of VVF and VCF.

Licences, permissions, backup jobs and monitoring after the move

In 8.x, hosts moved on their own need their licence keys in the target vCenter. In 9.1, Broadcom’s licensing documentation (updated 8 October 2026) says “You assign licenses to vCenter instances” through VCF Operations, and “The only assets in your environment which use the capacity of your primary licenses are ESX hosts.” A host added without unused capacity “remains in evaluation mode for up to 90 days”, and “The evaluation period starts when ESX is installed, not when it is added to the vCenter instance.” A host installed long ago may therefore have no evaluation time left, and a host whose evaluation has expired is disconnected from the vCenter. Check the capacity of the target vCenter before the first host arrives.

Roles, permissions, alarm definitions, tags, content libraries and folders belong to the source vCenter or its SSO domain, not to the hosts, so document them and recreate them at the target before VMs arrive.

Veeam’s user guide for version 13, to which Veeam’s KB 2136 now redirects, says Veeam Backup & Replication “tracks VMs in jobs using Managed Object Reference IDs (MORef-IDs), which change after migration or recreation of vCenter”, and names the VM Migrator utility in its PowerShell module to resolve the mismatch. Veeam’s PowerShell reference asks for a configuration backup before the utility is used, and says not to run backup jobs for VMs from the new vCenter until the work with it is finished. Plan the job changes before the cut-over. Monitoring, scripts and service accounts that point at the old vCenter move too, and the old appliance stays on until nothing queries it.

vCenter consolidation plan

1. Inventory every vCenter: version and build, SSO domain, ELM state, clusters, CPU vendor and EVC mode, switch type, vSAN services, licences and registered solutions.
2. Choose the target vCenter and the cluster layout, and decide per cluster whether hosts or VMs move.
3. Build the target side: distributed switches and port groups, storage policies, roles, permissions, tags and folders.
4. Take file-based backups of all vCenters, export every distributed switch, and confirm the restore path.
5. Move a pilot cluster or a batch of non-critical VMs, and check HA, DRS, backups and monitoring on it.
6. Move the remaining clusters or VM batches in agreed maintenance windows, ordered by application dependency.
7. Repoint backup jobs, monitoring and automation, and check licence capacity at the target.
8. Retire the empty vCenter after a final backup, and remove it from DNS, the identity provider and registered solutions.

A VM moved with Advanced Cross vCenter vMotion can move back while both vCenters run, and a host can return to its old vCenter while that vCenter and its switch configuration exist. A repoint is rolled back from the file-based backup or, in ELM, the offline snapshots.

The estate and licence audit of our VMware optimisation service covers versions, subscriptions and actual resource usage of every vCenter you run. Send us your vCenter inventory through the form below, with the builds, SSO domains and the vCenter you would keep.

What we do

Our VMware optimisation service starts with an estate and licence audit of versions, subscriptions and actual resource usage. Host and cluster consolidation is part of its licence and cost optimisation, and our engineering partner Vixen.UNO carries out the cross-cluster migrations in agreed maintenance windows, step by step, with a rollback plan at every stage. Support under an agreed SLA follows, and the price of the technical assessment is fixed before work begins.

FAQ