For most of the last decade the default answer to a refresh was hyperconverged. Fold compute and storage into one appliance, scale by adding nodes, manage it all from a single pane. It was a genuinely good idea for a lot of estates, and it still is. But the pendulum is swinging, and a growing number of organisations are quietly putting storage back onto external arrays. This is not fashion. It is a rational response to how the maths has changed.
The vSAN bill is the trigger
The single biggest driver is licensing. Under Broadcom, VMware moved to per core subscription and folded vSAN capacity into the VMware vSphere Foundation and VMware Cloud Foundation bundles. For estates that lean heavily on vSAN, the storage you used to treat as a sunk hardware cost is now wrapped into a recurring per core subscription that climbs with every renewal.
That reframes a question most people had stopped asking. If a meaningful slice of your VMware bill is really paying for software defined storage, is that the most cost effective way to hold your data? For some workloads the honest answer is no. An external array sits outside the vSAN portion of the licensing maths, which means you can buy and refresh that capacity on its own terms rather than renting it through the hypervisor.
You refresh storage and compute on different clocks
The second driver is older than Broadcom and just as important. Compute and storage do not wear out at the same rate, and they do not need upgrading at the same rate. A hyperconverged appliance ties them together anyway. When you add a node for more capacity you also pay for compute you may not need, and when your processors age out you disturb the storage layer to replace them.
Pulling storage onto an external array breaks that coupling. You refresh the hosts when the compute case demands it and the array when the storage case demands it. For finance teams trying to smooth capital cycles, and for architects tired of forklift upgrades that touch everything at once, that separation is worth real money and real risk reduction.
Scaling stops being lumpy
Hyperconverged scales in node sized steps. If you need more capacity you add a node, and you get a fixed ratio of compute and storage whether you wanted that ratio or not. Capacity heavy workloads end up dragging along compute they will never use, and compute heavy workloads run short of cores long before they run short of space.
A disaggregated design lets each layer scale on its own. You grow the array when you need terabytes and grow the host count when you need cores. The result is less stranded capacity on both sides, which is exactly the inefficiency that drove a lot of consolidation projects in the first place.
The arrays grew up while everyone was looking elsewhere
There is also a quieter reason. Modern external arrays are not the boxes people remember from the move to hyperconverged. All flash is now normal, NVMe and NVMe over Fabrics have closed much of the latency gap that once made local storage feel faster, and data services like snapshots, replication, immutability and inline data reduction are mature and well understood. The operational simplicity that hyperconverged promised is now available from an array with a clean management model, without the licensing entanglement.
So the trade that used to favour hyperconverged, simplicity in exchange for some flexibility, is no longer such a clear trade. You can have a simple operating model and keep the layers separate.
The honest counterpoint
None of this means hyperconverged is finished, and anyone telling you to rip it out is overselling. For smaller estates, for edge and remote sites, for teams who genuinely value one vendor and one support call, and for workloads that fit the node ratio cleanly, hyperconverged remains an excellent fit. The fused model is elegant when it suits you, and the cost of disaggregating, a storage network, more moving parts, a migration, is real and should not be waved away.
The point is not that external is better than hyperconverged. The point is that the decision deserves to be made again, on today’s numbers, rather than assumed from a choice you made five years ago when the licensing and the arrays both looked different.
Even Dell is pointing this way
It is telling that the signal is coming from inside the hyperconverged camp. Dell, whose VxRail was one of the defining hyperconverged platforms, has repositioned VxRail and is steering its messaging toward Dell Private Cloud and disaggregated infrastructure. When the vendor that sold you the fused appliance starts talking about separating the layers, it is worth noticing.
What to do about it
If you run a hyperconverged estate and a renewal or a refresh is on the horizon, treat the architecture as an open question rather than a settled one. Model what your vSAN capacity is actually costing you inside the VMware subscription. Look at whether your compute and storage really do age and grow together, or whether you have been paying for the convenience of pretending they do. Then decide on evidence.
For the deeper architecture view, our guide on moving from VxRail to external storage walks through the disaggregation decision in detail, and what the vSAN changes mean for your storage strategy covers the licensing angle specifically. If you are weighing the whole question from scratch, start with choosing enterprise storage.
The right answer is still going to vary by estate. What has changed is that external arrays belong back on the shortlist, and for more organisations than a year ago, they are winning a place on it.