Leaving VMware Is a Hardware Decision — and in 2026 the Two Destinations Moved in Opposite Directions

Written and maintained by Haink's infrastructure team · Verified against Microsoft, Nutanix and Broadcom licensing documentation, 29 August 2026 · authorized-channel, serial-verified supply

There is no shortage of writing about which hypervisor to move to. Almost none of it answers the question that actually decides the budget: what happens to the servers you already own.

That question used to have a boring answer — check the compatibility list, keep what fits. In 2026 it stopped being boring, because the two most common destinations changed their positions on it within weeks of each other, and they changed in opposite directions. Nutanix now advertises your existing hardware as an asset to carry across. Microsoft closed the door on bringing your own. If your migration plan was written before June 2026, one of its central assumptions is probably wrong.

What changed, and when

Nutanix went toward reuse

Nutanix runs on its own NX appliances, on OEM platforms from Dell, HPE, Lenovo, Cisco and Fujitsu, and on third-party x86 servers. The company's own hardware-platforms page makes the pitch explicitly: "Maximize the value of your existing hardware, including vSAN Ready Nodes, by transitioning those assets to Nutanix."

The catch is the one that always applies to compatibility lists, and it catches people every time: the list is by specific platform and firmware level, not by product family. A PowerEdge or ProLiant generation being listed does not mean your particular configuration is. Drive controllers, boot media and NIC models are all in scope. Verify the actual part numbers you own before a single line of the business case assumes reuse, because that assumption is usually worth six figures on an estate of any size.

Azure Local went the other way

On 16 June 2026 Microsoft consolidated the Azure Local hardware model from three categories to two. Validated Nodes — the flexible option, where you could assemble a solution from components or buy a partial configuration — was removed as a selectable category. What remains is Premier Solutions and Integrated Systems, both of which require joint Microsoft and hardware-vendor support integration.

Existing validated deployments stay supported. But the upgrade path is not automatic: Microsoft's guidance is to consult your partner and OEM, and notes that where a move from a validated solution to Premier is possible at all, "this requires a redeployment." A redeployment is a migration project, not a firmware update.

The market reaction tells you how material the change was. Cisco issued an end-of-life notice for its Azure Local offering on 24 July 2026, with sales stopping in October 2026, rather than re-engineer its bundles to meet the new categories. A vendor walking away from a Microsoft platform six weeks after a requirements change is not a small signal about the cost of compliance.

Licensing moved at the same time, into three host-fee tiers by deployment shape: roughly $10 per core per month for Storage Spaces Direct only with full Azure Hybrid Benefit eligibility, about $20 per core per month where SAN is involved either alongside S2D or on its own with no hybrid-benefit exemptions, and custom pricing for disconnected deployments. Treat those as orientation and confirm against Microsoft Product Terms, which Microsoft itself names as the authoritative source — but note the shape of it, because it prices the disaggregated SAN design at roughly double the hyperconverged one, and that is a design decision made at hardware-selection time.

If you stay, the hardware maths changed too

Staying is a legitimate outcome, and plenty of estates should. But the licence model no longer rewards the node design that used to be normal.

VMware licensing is an annual subscription metered per physical CPU core, with a 16-core minimum per CPU. Billable cores are the sum of max(actual cores per CPU, 16) across every licensed processor. The consequence at the hardware level is direct: a pair of 12-core CPUs bills as 32 cores. Low-core processors are penalised, and the optimal node drifts toward fewer, denser hosts than an estate designed in the per-socket era — though not all the way to the top SKU, for reasons worked through in choosing a server generation under per-core licensing.

The second consequence is less well known and catches capacity-heavy estates. The vSAN entitlement is granted per licensed core — 1 TiB per core under Cloud Foundation, 0.25 TiB per core under vSphere Foundation. Storage capacity is therefore bought with cores. A cluster that is large on disk and modest on compute is the expensive shape under this model, and no amount of drive-price negotiation fixes it. If that describes your estate, the honest answer may be that storage belongs outside the hyperconverged layer entirely — which is a hardware decision, taken before the renewal, not after.

The reuse question, answered properly

"Can we reuse the servers" is not one question. It is five, and the business case fails if any of them is answered optimistically:

1. How old is the fleet? Servers bought in 2019–2021 will exit support inside the life of the new platform. Carrying them across buys eighteen months and a second migration — usually the worst of both outcomes.
2. Does the exact model appear on the target's compatibility list? Model and firmware, not family. This is the single most common false assumption in migration business cases.
3. Does the drive layout suit the target? Modern HCI storage layers assume all-flash and increasingly NVMe. A hybrid ReadyNode built for a previous generation of vSAN may be compatible on paper and disappointing in production.
4. Is the network ready? Storage traffic on the new stack may need more than the fabric was specified for. A migration that quietly turns into a network refresh is a different budget conversation, and it is better to have it early.
5. Where does the data live during the conversion? Reusing hardware normally means evacuating workloads, rebuilding the nodes and migrating back — two passes plus interim storage. We covered exactly this pattern, with the arithmetic, in the HyperFlex migration analysis: on more than a few estates, two migration passes and temporary storage cost more than new nodes.

Answered honestly, these five frequently turn a reuse plan into a partial-reuse plan: the newest generation carries across, the rest is replaced, and the older kit exits through the secondary market to offset some of the capital. That is a normal and defensible outcome. It is simply not the outcome most business cases start with.

Node counts do not survive the move unchanged

A mistake we see repeatedly: sizing the new cluster at the same node count as the old one. Storage efficiency, resiliency model and the platform's own minimum are all different between stacks, and they move the number in both directions.

The floors alone differ materially — Cloud Foundation needs four nodes for a management domain, vSphere Foundation three hosts, Nutanix three for production with single-node supported at the edge, and Azure Local will run on one machine and scale to sixteen. The full comparison, with the node specifications behind it, is in which appliance series for which hypervisor. On a two-socket current-generation node, one node either way is routinely the difference between two budget brackets.

Beyond the floor, size from committed rather than allocated resources, subtract the resiliency overhead the new stack applies rather than the one the old stack applied, and add N+1 — the arithmetic, with the raw-capacity factor for each scheme, is in sizing an HCI cluster. Whether hyperconverged is the right destination shape at all — against three-tier with external storage — is worth settling first; we cover that in choosing an HCI platform, and the VxRail versus Nutanix comparison covers the platform choice underneath it.

What actually goes in the budget

Hardware is frequently the smallest line, which is why hardware-led migration plans overrun. The full picture:

Lead times decide your cutover date, not your decision date

Hyperconverged appliance lines are configure-to-order, not stock lines. Our published lead time for ThinkAgile VX, HX and MX is 3–6 weeks as of August 2026, against days to a week for standard rack servers from Hong Kong stock. The difference between stock and BTO/CTO is a scheduling input, not a footnote: a four-node and a seven-node cluster ship on the same timeline, but discovering the seventh node after the order is placed costs another full cycle and, frequently, a missed maintenance window.

At cluster scale the pricing mechanism changes as well. Special-bid and project pricing is registered against the specific opportunity rather than applied as a list discount, which means the structure has to be settled before the quote, not negotiated after it. And for multi-site or cross-border programmes, a twelve-node cluster does not have to land as one shipment — staging by rack against a phased cutover is usually cheaper than warehousing hardware while waiting for a data-hall window.

When leaving is the wrong call

We supply the hardware either way, so there is no reason to sell a migration that does not pay:

• When the three-year delta does not cover the move. Compare the renewal against the fully loaded migration cost from the table above — not against the hardware quote. On a number of mid-sized estates the renewal still wins.
• When the estate is small. Below roughly four nodes, migration overhead and the target platform's own minimums dominate the arithmetic, and the saving is eaten by the project.
• When you are mid-refresh. Hardware bought in the last eighteen months has not earned its keep. Time the platform change to the refresh cycle rather than fighting it.
• When you cannot staff the destination. A stack your team does not know is an operational risk that outlives the licence saving. This is the reason migrations fail most often, and it never appears in a spreadsheet.
• When the real problem is elsewhere. If the driver is data residency or getting out of public cloud rather than the licence itself, the destination question is different — see cloud repatriation for VMs and storage, or cloud-exit AI infrastructure if the workloads are GPU-bound.

Frequently asked questions

Can we reuse our existing servers if we move to Nutanix?

Often yes. Nutanix runs on its own appliances, on OEM platforms from Dell, HPE, Lenovo, Cisco and Fujitsu, and on third-party x86 servers, and the company explicitly promotes transitioning existing hardware including vSAN ReadyNodes. Verify the specific model and firmware level against the hardware compatibility list before the business case relies on it — family-level compatibility is not the same as your configuration being listed.

Can we reuse our existing servers for Azure Local?

Not for new deployments. Microsoft removed Validated Nodes as a selectable category on 16 June 2026, leaving Premier Solutions and Integrated Systems, both of which require joint Microsoft and vendor support integration. Existing validated deployments remain supported, but Microsoft's guidance notes that moving to Premier requires a redeployment where it is possible at all.

Why did Cisco stop selling Azure Local?

Cisco's offering was built on the Validated Nodes model. When Microsoft removed that category, Cisco issued an end-of-life notice on 24 July 2026 with sales ending in October 2026 rather than re-engineer its bundles for the remaining categories. It is a useful signal about how much the requirements change actually cost vendors.

How is VMware licensed now, and does it change what hardware we should buy?

It is an annual subscription metered per physical CPU core with a 16-core minimum per CPU, so billable cores are the sum of the greater of actual cores or 16 across every processor. Yes, it changes hardware selection: low-core CPUs are penalised, and because the vSAN entitlement is granted per licensed core — 1 TiB per core on Cloud Foundation, 0.25 TiB on vSphere Foundation — capacity-heavy, compute-light clusters are the expensive shape.

Do we get any credit for the VMware licences we already own?

No. Moving to another vendor's platform is a new purchase, and unused term on a right-to-use subscription is not refunded — it runs to expiry. Budget the new licences at full cost and treat any transitional offer from the destination vendor as a bonus rather than a plan.

Should the new cluster have the same number of nodes as the old one?

Almost never. Storage efficiency, the resiliency model and the platform's own cluster minimum all differ between stacks. Size from committed rather than allocated resources, apply the new stack's overhead rather than the old one's, add N+1, then check the destination's floor — four nodes for a VCF management domain, three for vSphere Foundation and Nutanix, one for Azure Local.

How long does the hardware take to arrive?

Hyperconverged appliance lines run 3–6 weeks to order as of August 2026; standard rack servers ship from Hong Kong stock in days to about a week. Node count needs settling before the order, because adding a node afterwards costs a full lead-time cycle.

Related

• Which ThinkAgile series for which hypervisor — node specifications and the cluster minimums that set your entry price
• VxRail vs Nutanix — the platform comparison behind the destination choice
• Choosing an HCI platform — whether hyperconverged is the right shape at all
• HyperFlex migration — the same reuse-versus-replace arithmetic, worked through on a closed platform
• Lenovo ThinkSystem selection — workload-to-model sizing if you are rebuilding on rack servers
• Enterprise storage selection — relevant if storage is coming back out of the hyperconverged layer
• Server refresh and consolidation — what a 4:1 consolidation actually saves, and why the licence line is not part of it
• Buying 20–60 servers as one project — the procurement sequence, from registration to staged delivery
• ITAD and the secondary market — recovering value from the nodes that do not carry across
• Sovereign cloud infrastructure — 40 nodes, 7,680 vCPUs, 96 TB NVMe, national data residency

Sources

• Microsoft Community Hub — Azure Local licensing and hardware ecosystem additions, June 2026 (Validated Nodes removed, Premier and Integrated Systems remain, redeployment required, host-fee tiers)
• The Register — Cisco retires its Azure Local offering (EOL notice 24 July 2026, sales stop October 2026)
• Nutanix — hardware platforms ("Maximize the value of your existing hardware, including vSAN Ready Nodes"; OEM and third-party server support)
• Nutanix — hardware compatibility lists (per-platform and firmware-level verification)
• Microsoft Learn — Azure Local system requirements (1–16 machines; stretched clusters 4–16 across two sites)
• VMware licensing changes — VCF and VVF (per-core subscription, 16-core minimum per CPU, 1 TiB and 0.25 TiB vSAN entitlement per licensed core)
• Lenovo Press — ThinkAgile FX Series (hardware validated for VMware, Microsoft and Nutanix stacks)