VMware host refresh: replacing ESXi hosts by rolling replacement or a new cluster

How to replace ESXi hosts in a VMware cluster

A VMware host refresh, the hardware refresh of a vSphere cluster, follows one of two patterns. In a rolling replacement, new hosts join the existing cluster and the old ones leave it one at a time, while Enhanced vMotion Compatibility (EVC) keeps vMotion working across CPU generations and vSAN moves each old host’s data before it goes. In the second pattern, you build a new cluster beside the old one and move the VMs across with vMotion, changing compute and storage in one step. Both keep VMs running as long as old and new hosts use CPUs from the same vendor. A change from Intel to AMD, or back, needs cold migration with each VM powered off. Broadcom calls the hypervisor ESX from version 9.0 and ESXi up to 8.x.

Broadcom’s EVC FAQ, KB 313545, states for the first pattern that “With EVC, full cluster upgrades can be achieved with no virtual machine downtime whatsoever.” Which pattern fits depends on the vSAN architecture, the vLCM image, the ESX version the new servers need and licence capacity during the overlap.

Broadcom KB 313545, KB 432894, KB 444762 and KB 424294; vSphere 8.0 documentation on CPU compatibility, EVC and migration (16 September 2026); VCF 9.0 licensing model (29 September 2026). The rollback and licence rows are our reading of these rules.

Our VMware optimisation service runs cross-cluster migrations in agreed maintenance windows, step by step, with a rollback plan at every stage. Tell us how many hosts and clusters you are replacing, with the CPU models on both sides.

Rolling replacement inside the existing cluster

Rolling replacement suits a cluster whose new servers keep the CPU vendor, the vSAN architecture and the server maker of the old ones. KB 444762 states that “vSAN requires architectural consistency across all nodes”, and KB 424294 says vLCM images for heterogeneous hardware clusters “are only supported starting in ESX 9”. Add the new host before you remove an old one. Broadcom’s VCF 9.0 page on adding a host to a vSAN cluster says the host “enters maintenance mode before the ESX host is added”, asks you to confirm that its drivers, firmware and storage I/O controllers are listed in the Broadcom Compatibility Guide (BCG), and recommends uniformly configured hosts.

On three hosts, Ensure accessibility is “the only evacuation mode available”, and Broadcom’s maintenance mode page calls it “not appropriate if you want to remove the host from the cluster permanently”. A fourth host with spare capacity, added first, makes Full data migration possible. Before each evacuation, the data migration pre-check and the Confirm Maintenance Mode dialog show whether capacity suffices, how much data moves and how many objects would become non-compliant or inaccessible.

Broadcom TechDocs, vSAN 8.0 administration, place a member of a vSAN cluster in maintenance mode (9 September 2026); KB 326861 and KB 432894, read on 10 October 2026.

The vSphere 8.0 limits allow 8 simultaneous vMotion migrations per host on 10 GbE and 4 on 1 GbE, so a host with 40 VMs empties in at least five rounds. KB 326861, for vSAN 7.x and 8.x, then lists the steps to retire it: wait until the resync has finished, remove the disk groups on OSA or the disks on ESA, move the host out of the cluster, remove its leftover unicast agent entries on the remaining hosts and shut it down.

New cluster beside the old one: vMotion between clusters

A new cluster fits when vSAN moves from OSA to ESA, when the new servers come from another maker and need their own vendor and firmware add-ons, or when you want the old cluster untouched as the way back. Broadcom’s KB 432894 says “Direct migration from vSAN OSA to ESA is not possible”, because the two “use fundamentally different on-disk formats and data paths”, and its side-by-side route builds a new ESA cluster and moves the VMs with Storage vMotion. Our comparison of vSAN ESA and OSA covers the ESA ReadyNode profiles for the new hosts.

Inside one vCenter, Broadcom’s vSphere 8.0 documentation states that “vSphere vMotion to another host and datastore is possible in vSphere environments without a shared storage”, and each host “must be licensed for vSphere vMotion”. Such a move counts as vMotion without shared storage, which the 8.0 limits cap at 2 per host at once, against 8 for vMotion alone. The split of a new estate into clusters is the subject of our vSphere cluster design guide.

Changing CPU vendor: cold migration between Intel and AMD

For live migration, the vSphere 8.0 documentation requires “that the processors of the target host provide the same instructions to the virtual machine”, and the processors “must come from the same vendor class (AMD or Intel) to be vMotion compatible”. EVC does not change this, since KB 313545 states that “An EVC-enabled cluster only allows CPUs from a single vendor to be used in the cluster”.

Cold migration is the documented route. Per Broadcom, “CPU compatibility checks do not apply when you migrate powered off virtual machines with cold migration”, and a suspended VM must still meet the CPU requirements of its new host, so a move to another vendor needs the VM powered off. The outage per VM covers the guest shutdown, the copy of its files when the datastore changes and the first boot on the new host, so plan it per application in maintenance windows.

EVC mode for the new hosts: choosing, raising, lowering

KB 313545 explains how to find the EVC modes a CPU supports: search the BCG for the server model or CPU family, select the CPU series and, for 8.0 Update 3 and 9.x, open “Enhanced vMotion Capability Modes”. The newest modes in its list, which covers vCenter 8.0 Update 1 and 2 as read on 10 October 2026, are Intel “Sapphire Rapids”, which includes Emerald Rapids, and AMD “Zen 4”; for later processors the BCG entry of the server is the reference. KB 450883 adds that RHEL 8 VMs fall back to Ice Lake on a Granite Rapids baseline, so check guest support first.

Set EVC before the first new host joins. If the cluster runs without EVC today, enable it at the old hosts’ own generation; the instruction to power off VMs applies only to VMs on hosts “with a feature set greater than the EVC mode” you enable. When the last old host has left, raise the mode. Per the 8.0 documentation, “Running virtual machines can remain powered on”, but new features reach them only after a full power cycle, and “Rebooting the guest operating system or suspending and resuming the virtual machine is not sufficient.” Setting vmx.reboot.powerCycle to TRUE turns the next guest reboot into a power cycle. Lowering the mode later requires powering off VMs that run above it, so in a new cluster keep the old cluster’s mode until the old cluster is gone.

ESX version, vLCM image and vSAN listing of the new hosts

If the new server model is listed in the BCG only for ESX 9, upgrade vCenter first. KB 424129 states that “vCenter 9.0 can manage ESX version 8.0 hosts in the same cluster with ESX 9.0 hosts”. Old hosts on Cascade Lake Xeons or EPYC 7002 processors are deprecated for VCF 9.x in KB 318697, which adds that “Deprecated mode means it is still Supported by VMware”. Which existing hosts run ESX 9 is in our ESX 9 hardware requirements guide.

When a host joins an image-managed cluster, the add-host wizard asks you to select the existing cluster image or import one from a host. Prepare that image before the servers arrive, with the base image, the server maker’s vendor add-on and, for firmware, its hardware support manager. Clusters still on baselines and clusters mixing server makers are covered in our guide to moving from vLCM baselines to images.

Licences during the overlap and for retired hosts

Broadcom’s VCF 9.0 licensing model states that “The only assets in your environment which consume the capacity of your primary licenses are ESX hosts”, at a minimum of 16 cores per physical CPU, and that licences are assigned only to vCenter instances. While old and new hosts share vCenter, both consume cores. A host added without spare capacity stays in evaluation mode for up to 90 days, counted from the ESX 9.0 installation, after which it is disconnected from vCenter.

For VCF 9.1, KB 445407 describes how capacity comes back: remove hosts that no longer need to be managed from the vCenter inventory, or decommission them in SDDC Manager where it manages them, and allow 5 to 10 minutes for VCF Operations to reclaim the cores. The counting rules are in our VMware licensing guide, and the number and core count of the new hosts in our guide to host consolidation under per-core licensing.

Refresh procedure, step by step

The order is ours, built from the Broadcom documents above, with a rollback point after each step.

1. Take an inventory per cluster: host and CPU models, EVC mode, vSAN architecture, vLCM image, vCenter and ESX or ESXi versions.
2. Check the new server model, CPU, adapters, drives and controllers in the BCG for the target ESX release.
3. Choose rolling replacement or a new cluster per cluster, and confirm licence capacity for the overlap.
4. Enable or confirm EVC at the old hosts’ mode, and upgrade vCenter where the new hosts need it.
5. Prepare the cluster image and the vMotion and vSAN networking for the new hosts.
6. Add the first new host, remediate it to the image and check vSAN health before any VM moves.
7. Evacuate one old host with Full data migration after the pre-check, or move one batch of VMs to the new cluster with vMotion.
8. Retire the old host: disks or disk groups removed, host out of the cluster and out of the vCenter inventory.
9. After the last old host, raise the EVC mode and power-cycle the VMs in maintenance windows.
10. Sanitise and record the old drives before they leave your control.

We supply the new servers with manufacturer warranty, and engineering is by our partner Vixen.UNO. Write to us with your cluster list and refresh dates, and we work through the order of steps with you.

Retiring old hosts and sanitising their drives

NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization, published in September 2025, supersedes Rev. 1 of 2014. Of its three methods, Clear applies logical techniques to “all user-addressable storage locations” against simple, non-invasive recovery. Purge makes “the recovery of target data infeasible”, even with laboratory techniques, and leaves the drive potentially reusable; Destroy reaches the same level and leaves the drive unusable for data. Rev. 2 points to IEEE 2883 for media-specific techniques and asks for the result to be verified and for “a certificate of sanitization” per device, with model, serial number, method, tool and verification.

Rev. 2 treats drives exchanged under warranty and not returned as outside organisational control. For vSAN, the vSAN 7.0 Update 1 release notes introduced PowerCLI and API commands to “Securely wipe flash storage devices before decommissioning from a vSAN cluster”. Boot devices and local VMFS disks belong in the same record.

What we do

Eurokommerz holds the contract and supplies the hardware under the solution, with EU invoicing, delivery and warranty under European law. Under VMware optimisation, our engineering partner Vixen.UNO takes a full inventory of your VMware estate and licences and modernises vSphere, vSAN, NSX and VCF, cross-cluster migrations included. Changes run in agreed maintenance windows with a rollback plan at every stage, followed by support under an agreed SLA. The first call is free of charge, and the price of the technical assessment is fixed before work begins.

FAQ