Moving a vSAN Cluster Between vCenters: Keep the Storage Together

Moving a vSAN cluster to another vCenter sounds like the kind of operation that should start with a very large storage migration. The name makes you picture copying every virtual disk, evacuating hosts, and finding somewhere to put several terabytes while you rebuild the cluster.

For the operation covered here, the objective is simpler: keep the existing storage cluster intact while handing management of its hosts to another vCenter. The hard part is making sure that the management change does not accidentally change the conditions that keep the storage working.

The procedural starting point is Broadcom KB 326849. This article explains the reasoning around that procedure, with additional official references beside the relevant decisions. Sources and command syntax were checked on 6 September 2026; this is a documentation-based walkthrough, not a claim that every combination below has been exercised in a lab.

What actually moves?

vCenter provides management and monitoring. It is not in the VM’s vSAN I/O path: the official vSAN FAQ explains that vSAN and running workloads can continue operating when vCenter is offline, although management operations become unavailable.

That separation is the reason this migration is possible. It is also a useful way to organize the change plan:

BEFORE                         AFTER

  vCenter A                      vCenter B
      |                              |
      | manages                      | manages
      v                              v
  +------------------+           +------------------+
  | H1  H2  H3  H4   |           | H1  H2  H3  H4   |
  | Existing vSAN    |           | Existing vSAN    |
  | objects + disks  |           | objects + disks  |
  +------------------+           +------------------+

       Same hosts. Same storage being retained.
             Different management owner.

This is different from moving selected VMs to a different storage cluster, replacing the hosts, or converting an OSA deployment to ESA. Treat those as separate projects. Combining them makes it much harder to identify which change caused a problem.

An available VM and a successfully migrated management environment are different acceptance criteria. A database answering queries does not tell you whether its backup job, storage-policy association, or new vCenter permissions are correct.

Choose the right procedure before choosing a host

The worked example below is a healthy, four-host, single-site cluster, with the same hosts and storage network throughout the move. It assumes that any encryption and network preparations have been completed before the first inventory change.

Use the following decision table before applying that example to your environment:

The File Services and HCI Mesh restrictions are in KB 326849. For stretched configurations, KB 326587 describes disabling and rebuilding the stretched configuration around the move, and a distinct recovery case when the old vCenter is lost. Its environment section lists vSAN 6.x: follow the main KB’s cross-reference, but validate its recovery instructions against your release before touching a witness.

For NSX, KB 443899 requires graceful NSX removal from the source transport nodes before the ordinary host migration, followed by installation and configuration afterward. It separately directs migrations of NSX Manager and Edge components to another procedure. That can materially change the outage and networking plan; it is not an extra checkbox at the end.

For VCF, KB 414650 documents restrictions on moving hosts between domains. An inventory move that works in vCenter is not proof that SDDC Manager’s lifecycle state remains valid. Establish the supported workflow for the specific VCF release and domain arrangement first.

1. Record the environment you need to reproduce

Write a small migration workbook. Its purpose is to answer questions when the source inventory is no longer the convenient place to look things up.

Check releases in the Broadcom Interoperability Matrix. Do not compare the numeric build numbers of different products as if they shared one version sequence. KB 312551 also notes that host and VM historical performance data is purged during the inventory move. Export anything you need for capacity history or incident comparison beforehand.

Take current, tested workload backups. Record direct ESXi access and out-of-band console access, and keep the necessary credentials available outside the cluster being changed. My recommendation is to give the change coordinator a short evidence sheet with one row per host, rather than relying on a scrolling terminal transcript.

Establish a host-side baseline

On every data host, collect these read-only checks:

esxcli vsan cluster get
esxcli vsan network list
esxcli vsan cluster unicastagent list
esxcli vsan debug object health summary get
esxcli vsan debug resync summary get

The ESXCLI vSAN reference documents these commands. Debug output can vary between releases; use the host’s --help where necessary rather than expecting identical formatting.

Record membership identities as well as counts. Four members is useful; knowing that they are the expected four is better. Check object health separately from resync: zero bytes awaiting resynchronization does not establish that every object is healthy. Broadcom documents a post-migration case with reduced availability and no active resync in KB 399504.

Choose a few application checks you can repeat quickly: a database query, a service login, a file read, or another meaningful transaction. Record their results before the move so you have something concrete to compare later.

2. Make the networking survive the handoff

A standard switch is configured on the host. A distributed switch has a vCenter-owned management configuration. Moving a host’s inventory entry does not transfer ownership of that distributed switch to the new vCenter.

KB 337625 describes using a standard switch as a temporary bridge. This is the path used here:

Existing networking       Temporary bridge       Final networking

  source vDS                 host vSS             destination vDS
      |                         |                        |
      +------ migrate --------> + ------ migrate ------>+

  management VMkernel      stays reachable        stays reachable
  vSAN VMkernel           stays reachable        stays reachable
  VM port groups          keep guest access      keep guest access

         Inventory changes happen while on the bridge.

Do this as its own controlled network change. KB 306406 calls out uplink mappings, VLAN and security settings, VM adapter assignments, and out-of-band access. LACP/LAG configurations and iSCSI port binding require additional planning. Do not take a generic “move one uplink” instruction and apply it blindly to an aggregated uplink design.

A useful review question is: after the next click, what physical path carries management, vSAN and guest traffic? If the answer is unclear, the network plan is not ready. A spare port group without a working uplink is not a migration bridge.

KB 426590 also discusses distributed-switch export/import and recommends the vSS bridge for stability. For this migration, follow its instruction to clear the option that preserves original distributed-switch/port-group identifiers. Do not confuse restoring the same switch with introducing a switch under a different vCenter. The main KB also requires a different destination vDS name to avoid stale-reference conflicts.

Test the actual VMkernel path

An ordinary ping from a laptop proves very little about host-to-host vSAN traffic. Select the vSAN VMkernel interface explicitly. These examples use documentation-only IPv4 addresses; replace vmk2 and the peer address with your recorded values.

# Basic reachability to another host's vSAN VMkernel IP
vmkping -I vmk2 -c 3 192.0.2.22

# If the intended end-to-end MTU is 1500
vmkping -I vmk2 -d -s 1472 -c 3 192.0.2.22

# Use this instead only for an intended end-to-end MTU of 9000
vmkping -I vmk2 -d -s 8972 -c 3 192.0.2.22

For ordinary IPv4 ICMP without IP options, 1472 bytes of payload plus 28 bytes of IP and ICMP headers equals 1500; 8972 plus 28 equals 9000. The -d test prohibits fragmentation. The interface and packet-size options are documented in KB 344313.

Repeat across the relevant peer paths, in both directions, after each networking transition. A small successful ping does not prove the configured MTU, sufficient bandwidth, or that every vSAN service port is reachable. Use the broader vSAN networking checks alongside it. Test management access to the destination vCenter and the required vMotion and guest networks separately.

3. Prepare the destination before adding hosts

Create the destination datacenter and an empty cluster. Keep destination HA and DRS disabled initially, configure the required EVC baseline in advance, and enable vSAN with the matching architecture and services. These are prerequisites in KB 326849.

Matching matters. An empty cluster that merely has “vSAN enabled” is not necessarily equivalent to the cluster being moved. KB 399504 shows how missing service settings and mismatched policies can leave a migrated environment unable to create a VM swap object. Treat enabling vSAN here as preparation to manage existing storage, not permission to claim, erase or recreate its devices.

EVC is a compatibility decision

Configure a compatible baseline while the destination is empty, and validate the CPU features already exposed to running VMs. EVC cannot retroactively take instructions away from a powered-on guest. The EVC FAQ explains the relationship between EVC and the features established at VM power-on.

There is an important difference in emphasis between the documents: the generic vDS host-move KB says to power off VMs when adding into an EVC cluster; the vSAN migration KB describes preparing EVC before the move. Neither is a reason to promise that your running VMs will be admitted. Check the actual compatibility result. If admission would hide features already in use, plan the necessary workload power-off or a supported alternative. KB 411077 documents that failure condition.

For the source cluster, inventory resource pools before changing DRS. The generic host-move guidance allows manual mode or disabling, but specifically says to retain DRS in manual mode for Cloud Director/Horizon dependencies. Keep this separate from the destination’s initial HA/DRS setting. See KB 312551.

Encryption has two separate questions

Ask both: can the new environment access the required keys, and does its cluster configuration describe the encrypted storage correctly?

For a Native Key Provider, back up the existing provider and restore that backup at the destination. A newly created provider with a familiar name is not the same key material. KB 424420 also demonstrates why encrypted/vTPM-enabled VMs need the original provider restored and its key identity checked. Audit VM encryption even if vSAN encryption itself is not enabled.

If the NKP backup fails, KB 422405 documents a failure caused by accessing vCenter through an alias rather than its official identity. Verify that you actually have the backup file and its password, not just a screenshot of the provider name.

For an external KMS, configure the existing provider and trust at the destination, preserving its KMS-cluster/provider name as specified in the main KB. Confirm access to the existing keys; this migration is not an opportunity to replace the provider without a separate key-management plan.

KB 408384 and the main migration KB reference restoreEsaEncryptionConfig.py. For the cross-vCenter case, the main KB specifies comparing the host encryption configuration, copying matching output as JSON to the new VCSA, and using its attached script once. Follow the current attachment’s instructions for your topology; the same-vCenter recovery example is not interchangeable with the cross-vCenter workflow.

The documented host-side collection command is read-only:

configstorecli config current get \
  -c 'vsan' -g 'system' -k 'vsan' -p 'encryption'

If outputs differ, stop and resolve that discrepancy. Keep collected encryption configuration in the restricted change record. Do not paste it into a public ticket or use a guessed script invocation against production.

4. Preserve the policies and their assignments

Separate the policy definition from the policy assignment. One tells you what the rules are; the other tells you which VM home or disk uses them.

Policy definition                 Assignment record

  Production-FTT1                  APP01 / VM home -> policy A
    failure tolerance             APP01 / disk 1  -> policy A
    placement rules               APP01 / disk 2  -> policy B
    reservations / limits

  Exporting the definition does not record this whole mapping.

PowerCLI can export a selected policy to a local file. Replace the example server and policy names, and use a new export path. Explicit server parameters keep the source and destination unambiguous when multiple connections are open.

$source = Connect-VIServer -Server 'vc-a.example.com'
$policy = Get-SpbmStoragePolicy -Server $source `
    -Name 'Production-FTT1' -ErrorAction Stop
if (@($policy).Count -ne 1) { throw 'Expected exactly one source policy.' }
$policyFile = Join-Path $PWD.Path 'production-ftt1.xml'

Export-SpbmStoragePolicy -Server $source `
    -StoragePolicy $policy -FilePath $policyFile

Get-SpbmStoragePolicy retrieves the definition; Export-SpbmStoragePolicy writes it to a file. Review each policy needed by this cluster rather than exporting unrelated policies and assuming the resulting directory is a migration plan.

After preparing the destination, import the reviewed definition. This creates a policy in the destination vCenter; it does not assign it to all VMs. If a policy with the intended name already exists, inspect its rules rather than blindly creating another one.

$destination = Connect-VIServer -Server 'vc-b.example.com'
Import-SpbmStoragePolicy -Server $destination `
    -Name 'Production-FTT1' -FilePath $policyFile

The file must be accessible to the PowerCLI client, as documented by Import-SpbmStoragePolicy. Compare the imported rules and compatible storage before using the new policy.

For assignments, inspect VM home and virtual disks. For example, this read-only sample examines one VM on the source:

$vm = Get-VM -Server $source -Name 'APP01' -ErrorAction Stop
Get-SpbmEntityConfiguration -Server $source -VM $vm | Format-List *

$disks = Get-HardDisk -VM $vm
if ($disks) {
    Get-SpbmEntityConfiguration -Server $source -HardDisk $disks | Format-List *
}

Get-SpbmEntityConfiguration supports both VM and hard-disk queries. Repeat the inventory for the migration scope and retain an unambiguous VM/disk mapping. Do not infer a data disk’s policy from the VM home’s policy.

5. Preserve membership before disconnecting anything

vSAN hosts need the correct peer information to remain one storage cluster. During the handoff, the two vCenters temporarily have incomplete inventories of that cluster. The host setting below prevents membership updates from that changing management view from replacing the peer information being preserved.

On every participating data host, set the flag before removing the first host:

esxcfg-advcfg -s 1 /VSAN/IgnoreClusterMemberListUpdates
esxcfg-advcfg -g /VSAN/IgnoreClusterMemberListUpdates

Verify the returned value is 1 everywhere, and record completion per host. This requirement and the consequences of omitting it are described in KB 426590.

The setting is a temporary guard around membership updates. It does not fix a wrong VLAN, create a missing physical route, or repair an already incomplete peer table. Use it only after the recorded cluster and networking checks are satisfactory.

For the ordinary four-host example, the unicast guidance describes peer entries for the other hosts, excluding the host itself:

H1 knows: H2 H3 H4        H2 knows: H1 H3 H4
H3 knows: H1 H2 H4        H4 knows: H1 H2 H3

                  One storage membership

This schematic excludes witnesses and special topologies.

Do not rebuild the lists just to make them look like this illustration. Manual unicast repair is a different procedure, involving correct identities and, where applicable, certificate thumbprints. Collect evidence and use the applicable recovery guidance if the baseline is already wrong.

6. Move one host, then prove the cluster still works

Use a written host order and complete each host’s tasks before starting another. At the source, disconnect the chosen host, wait for the task, then remove it from inventory. That is the host-inventory operation described in KB 312551, not deletion of VM files or decommissioning of storage.

At the destination, add the host at datacenter level first, wait for completion, then move it into the prepared cluster. The vSAN migration KB warns that adding it directly to the cluster can force maintenance mode. Follow its staging sequence.

Destination vCenter
|
+-- Datacenter
    |
    +-- H1                 <-- add here first; wait
    |
    +-- Prepared cluster
         +-- H1            <-- then move here; wait

One host passes its checks before the next host starts.

Use the recorded host identity when confirming the connection. If the wizard requests an unexpected maintenance action or reports an EVC incompatibility, pause instead of changing the plan mid-wizard. For this intact-cluster workflow, deliberately evacuating the host’s vSAN storage is not the intended inventory operation.

Understand the temporary split

Halfway through the example, the inventory can look like this:

  vCenter A inventory             vCenter B inventory
       H3 H4                           H1 H2
         |                               |
         +---------------+---------------+
                         |
             vSAN membership being preserved
                    H1 H2 H3 H4

This is an explanatory model of the intended handoff, not command output and not a recommendation to operate permanently across two vCenters. In this model, two hosts in the destination inventory does not mean the healthy storage membership should shrink to two. Compare the host-side member identities with your pre-change baseline.

The main KB discusses inventory and membership counts at different stages. Do not use an incomplete destination inventory as permission to accept a new storage partition. The unicast recovery reference uses host-side membership to verify that the storage cluster has formed correctly.

The checkpoint after each host

Repeat the earlier host-side checks on the moved host and compare with the peers. My suggested acceptance record is deliberately short:

If an application check fails, freeze the host sequence even if inventory tasks are green. If membership changes unexpectedly, collect output from multiple hosts before attempting recovery. Moving more hosts adds variables to an unresolved incident.

7. Finish the management handoff

Once all intended hosts are in the destination cluster and membership and object health are confirmed, restore normal membership updates on every data host:

esxcfg-advcfg -s 0 /VSAN/IgnoreClusterMemberListUpdates
esxcfg-advcfg -g /VSAN/IgnoreClusterMemberListUpdates

Verify 0 on each host. KB 326427 explains why this matters for subsequent additions and removals. Leaving the flag at 1 does not make the cluster safer; it leaves membership management deliberately incomplete.

Complete the planned transition from the temporary vSS to the destination vDS and repeat the network checks. KB 337625 describes that return path. Treat it as another change with its own checkpoint, not as housekeeping that can be rushed because the inventory move worked.

Reassociate policies in controlled batches

Apply the destination policies using the VM-home and disk mapping you captured. Matching policy rules on healthy hosts should avoid a layout-driven resync, according to the main migration KB; that is a conditional expectation, not a guarantee.

Start with a small representative batch, inspect tasks and compliance, and monitor resync before proceeding. If resync starts, let it finish before the next batch. Do not combine reassociation with a change from mirroring to erasure coding.

KB 405951 explains that a policy conversion can temporarily require both the old and new layouts. KB 327006 documents how resync can affect VM I/O through network or disk pressure. A policy cleanup that unexpectedly becomes a storage-layout change deserves its own capacity and performance assessment.

For a fresh compliance result, use Get-SpbmEntityConfiguration with -CheckComplianceNow on the destination VM and disks. Without that switch, the cmdlet can return cached compliance status. “Associated with the right name” and “freshly checked as compliant” are different pieces of evidence.

After stable operation is established, restore the intended HA and DRS configuration, resource pools and placement rules. Validate admission control and failover readiness; having moved the hosts does not by itself prove that the intended compute protection has been rebuilt.

When something goes wrong

Use symptoms to choose the next investigation. Avoid a general-purpose “click Remediate until green” recovery strategy.

The last row is an operational acceptance check, not a universal statement about how every backup or monitoring product handles the move. Test the products you actually use.

If the source vCenter is permanently lost, the main KB includes that scenario. The host-side records become more important because you cannot export the missing management configuration. Object inspection can provide clues about stored policy attributes, but it does not reconstruct permissions, automation, or a lost key backup. Escalate when the missing information prevents a safe match.

There is no useful universal “undo” command for a partly migrated cluster. A return to the source would have to respect the current network, membership, encryption and inventory state too. Preserve access, stop further changes, and choose a recovery path from the evidence. Do not use cluster-leave operations, disk reclamation or unicast-table deletion as experiments.

Define done before retiring the source

The final review should demonstrate three things:

STORAGE                         MANAGEMENT
Same intended membership        All hosts in destination
Healthy, accessible objects     Correct services and policies
Understood resync state         HA / DRS / permissions restored
             \                  /
              \                /
               APPLICATION OPERATIONS
               Transactions still work
               Backup / restore checked
               Monitoring and jobs checked

My recommendation is to keep the source available until the application and platform owners have accepted that evidence, while ensuring it cannot accidentally resume managing hosts already handed over. Test a backup and a representative restore through the destination integration. Where appropriate, test a noncritical VM’s lifecycle and a vMotion after the final networking and compute configuration is restored.

Record the result of every host’s flag reset, outstanding alarms and any planned follow-up work. Then retire the old management system through the normal process.

The most useful question throughout this migration is: what must still be true after the next step? Answer it for membership, networking, encryption and policy, and the sequence becomes much easier to reason about than a list of clicks.

References and validation scope

The principal procedure is Broadcom KB 326849 — vSAN cluster migration between vCenter Servers. Related official sources are linked beside their claims and examples above.

The main KB currently lists vSphere 7.x, 8.x and 9.x in its environment section; some linked articles have narrower version scopes. A link from the parent article does not establish that every recovery command applies unchanged to every release.

The ASCII drawings are explanatory schematics. The PowerCLI samples are intentionally small examples, not an unattended migration script. Command names and parameters were checked against the linked references; they were not executed against an ESXi or vCenter environment for this article. Validate the exact builds, dependencies and application acceptance tests in your own change plan.