Moving a vSAN cluster from one vCenter Server to another

vSphere 7 to 8 updates are slowly in full swing, many customers are migrating to October ’25 -> EOL for vSphere 7. Some of my customers want a brand new vCenter right away, because some of theirs are still from version 5, the ex-colleague fiddled in the Postgre database before he quit and so on and so forth – the reasons seem to be endless.

One of the most important workarounds is the migration of vSAN clusters from one vCenter to another. I would like to describe this process to you today.

First things first, let’s see how our vSAN cluster is doing. The cluster MUST be in a healthy state, such as here:

No warnings are allowed to be displayed, not to mention any errors:

We look at the virtual network infrastructure, i.e. whether there are standard and/or distributed switches and how they are set up:

The same applies to the vmk adapters, here it is important to know where the vMotion is running, how the vSAN is configured, etc.:

And now let’s start with the first step, exporting the distributed switch and its configurations:

The port groups must also be included for a smooth migration:

Then import the Distributed Switch on the new vCenter:

IMPORTANT: do not check the Box with:

Preserve original distributed switch and port group identifiers

And that’s it for the distributed switch:

Now build a new cluster on the new vCenter and activate only vSAN, no other service:

Additional important details:

• please never use Quickstart for vSAN Cluster Deployments due to dependencies in the subsequent lifecycle
• with a 2-node cluster, you cannot configure the deployment via the vSAN services, you have to configure the nodes and settings by hand, which is not more complicated as it sounds 😉
• with a 3 or more node cluster, the vSAN can be configured via the vSAN services; this blog post is about a 3-node cluster.
• you must ensure that the vSAN Storage Policy is available in the new vCenter in order to activate it under Performance Services. Either build it policy by policy, cluster by cluster, or use a PowerCLI script to export it and import it into the new vCenter (my preferation, makes life easier and safes a lot of time)

Inside the vSAN Configuration leave everything on default:

In each subsequent step, I recommend checking the unicast connection of the vSAN cluster to ensure that the nodes are connected to each other during the migration phase (regardless of whether they are Streched, 2node, Witness Appliance or Standard).

By using the following command, you get information on the UUID, IP address, host name, cluster member number and health status etc.:

esxcli vsan cluster get

Then the cross check takes place, the UUID from the upper command should be checked again in the unicast command. The node from which the command is executed is logically not displayed:

You can find more information about vSAN Unicast in the following KB: https://knowledge.broadcom.com/external/article?legacyId=2150303

esxcli vsan cluster unicastagent list

Disable the update of vCenter Server cluster members by running the following command on the ESXi hosts in the cluster. Ensure that you run the following command on all hosts. This command is also used to restart vSAN Cluster manually.

esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates

After the Ignore Cluster Member command, we immediately check again whether the cluster membership number has remained identical:

esxcli vsan cluster get

Before we prepare the individual nodes for migration to the new vCenter, please do not put the node into maintenance mode, we will migrate the node “opened heart” to the new vCenter.

Now we start with the actual “surgery”. First, we have to migrate the networks from a distributed switch to a standard switch including the physical adapters. Pay attention to what network components the switches have. Migrate the VMkernel Adapters one after the other and not at the same time to avoid downtimes.

This example shows that the port groups and VMkernel adapters have been migrated from the distributed switch to the standard switch:

After the migration, the distributed switch can be deleted, as the nodes in the new vCenter will be added to the imported distributed switch.

Now you can Disconnect the empty node und remove it from the old vCenter inventory.

After successfully removing the node from the old vCenter, it’s time to add it into the new vCenter. Please note that the new node should not be added to the Cluster directly but to the Datacenter Level. The node can then be moved into the cluster and added to the imported Distributed Switch.

Only continue with the next node when the newly added node has its previous state. After all nodes are in the cluster, you finally execute the vSAN Cluster commands again to ensure optimal operation.

esxcli vsan cluster get
esxcli vsan cluster unicastagent list

Finally set the Ignore Cluster Member back to 0 and everything should be in the green zone in the Skyline Health of vSAN.

esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMemberListUpdates

I would like to Thank my Friend and Brother in Arms – Merlin for providing me the Screenshots. This is it for this Blog post, if you have any Questions please use the comment section below. 🙂