A new feature needs a newer virtual hardware level
Something in the current vSphere release requires it, and someone has to confirm the blast radius first.
VMware Cloud Foundation guide
The newest virtual hardware version is not automatically the right one. Kritical helps infrastructure teams make the compatibility decision around the whole operating path — every host, every recovery target and every backup tool that must keep working — not just the newest number available in vSphere.
On this page
Jump to the part that matches the problem or decision in front of you.
Compatibility questions rarely arrive on their own.
Something in the current vSphere release requires it, and someone has to confirm the blast radius first.
New hosts run a newer ESXi build than the oldest node in the cluster, and the gap has to be reconciled.
The virtual machine restored, but wouldn't power on where it was supposed to.
Choose compatibility around every place the virtual machine may need to run: the oldest host in the cluster, recovery infrastructure, backup and replication tooling, test environments and any planned migration target. An upgrade that works on one host can still remove a recovery option the business depends on.
Confirm the ESX or ESXi releases that may power on, move or recover the virtual machine. Mixed-version clusters and recovery sites make the oldest required platform part of the decision.
Check the guest operating system against the current VMware compatibility guidance instead of assuming a newer guest requires the newest virtual hardware.
Include backup, replication, restore, disaster recovery and isolated test workflows before changing compatibility.
The virtual hardware version defines the devices and platform capabilities exposed to the guest. It's separate from the guest operating system, VMware Tools and the application itself — treat those as related lifecycle decisions, not one upgrade button.
A compatibility level can affect available virtual devices, CPU and memory limits and platform features. We confirm the feature you need before changing it.
Tools and virtual hardware have different release and support considerations. Updating one does not automatically require updating the other.
The platform change still needs an application-aware check. A successful power-on is not the same as a successful business service.
Broadcom's compatibility table reviewed in September 2026 maps ESX 9.0 to virtual hardware version 22. VMware Cloud Foundation and vSphere have continued to move, including vSphere 9.1, so we verify the current matrix and product documentation at the time of change rather than copying a version number from an old build guide.

Inventory the current compatibility level, host and cluster versions, guest support, snapshots, backup state and recovery targets. We agree the validation workload and rollback approach before changing a production virtual machine, and group machines by dependency and risk instead of applying one policy everywhere.
Bring the current vCenter and host versions, the affected workloads and the change you're considering. We'll help establish the safest useful next step, priced in writing.
We confirm the scope of the compatibility question and whether it needs a full VMware Cloud Foundation assessment or a bounded change.
Send the systems and constraints involved and we quote the work.
No. Use the newest level that delivers a required benefit while remaining compatible with the hosts, recovery platforms and operational tools the VM must use.
Not automatically. Guest support and VM hardware compatibility are separate questions. We check the current VMware compatibility guidance for the specific guest and platform combination.
Yes. We can scope an assessment across host versions, clusters, virtual machine compatibility, guest support, backup and recovery dependencies, then turn the findings into an upgrade or migration plan.
Usually a virtual machine that can no longer be recovered on the host or backup platform you assumed would still support it. That's why the assessment covers recovery infrastructure.
Yes. We group machines by dependency and risk rather than applying one blanket policy, so higher-risk systems get more scrutiny than low-risk ones.
Tell us what you want to achieve, what you have today and when it matters.