Leaving vSphere Without a Storage Refresh: What Happens to the Array You Already Own

There is a version of the VMware® exit conversation that never gets written down, and it happens after the meeting. Somebody walks back to their desk, opens the asset register, and finds the array. Four years old. Support paid through to a date eighteen months out. Two thirds depreciated. Nowhere in the migration plan, because the migration plan is about the hypervisor.

That is the honest starting position for most estates. The licensing change forces a decision about the platform, and the platform decision arrives next to an asset that nobody was planning to touch this year. Two clocks, both running, and only one of them is on the project board.

The way this usually resolves is not with a decision. It resolves by default, in whichever direction the first vendor conversation pushes, and both directions have a sales motion behind them. One says keep the array and change the layer above it. The other says replace everything while the estate is already open. Neither is wrong in general and neither is right in general, which is the problem with hearing them as pitches rather than as options.

So this article is about the transition decision rather than the destination. It is not another argument for replacing your SAN; we have written that argument already, at length, in why software-defined storage beats a traditional SAN, and it stands. This is the question that comes before it: whether the array comes through the exit with you, and what you are actually signing up for either way.

Two decisions arrive in the same meeting

The reason these feel like one decision is that in vSphere they were one thing. The array presented LUNs, VMFS sat on top of them, the hypervisor owned multipathing and pathing policy, and the operational surface a platform team touched was the datastore. Below the datastore was somebody else’s job, usually a storage team with its own tooling and its own renewal calendar.

Take the hypervisor out and that stops being true. The layer that used to sit between your workloads and your array is the layer you are removing. Whatever replaces it, whether that is KubeVirt, Red Hat® OpenShift® Virtualization, or a move of the workload itself into containers, has to form its own relationship with block storage. The array does not care about that. It carries on presenting LUNs to whoever asks correctly.

Which means the question is not really technical first. It is a question about two calendars:

• The licence clock. When the renewal lands, what it costs, and whether the estate has to be somewhere else by then. This is the clock that started the project, and it is the one with a date everyone already knows.
• The refresh clock. When the array leaves support, when its maintenance renewal arrives, and when its capacity or performance envelope stops fitting the workload. This clock was running before the licensing change and is unaffected by it.

Put them next to each other on one page and the answer is often obvious within a minute. An array with four years of support left and plenty of headroom is an asset to defer. An array whose maintenance renewal lands two quarters after your migration window is not being kept, it is being paid for twice. Most estates are somewhere in between, and that middle is where the default answer does the most damage, because deferring feels free and it is not.

One more framing point, because it gets lost. Keeping the array is not the same as avoiding the work. If the array stays, everything attached to it stays: the fabric, the zoning, the multipathing assumptions, the vendor relationship, the specialist knowledge held by two people, and the refresh project itself, which is now scheduled to happen separately from the migration rather than inside it. You have not removed a project. You have moved it, and you have committed to opening the estate twice.

What keeping the array buys, and what it keeps costing

Start with what array retention genuinely delivers, stated as strongly as the vendors state it, because it is real.

It defers capex. You bought capacity and you have not finished using it, and writing off a partly depreciated asset to buy an equivalent one is a hard conversation to have with finance during a year that already includes an unplanned platform migration. It preserves a known performance envelope: the array’s behaviour under your actual workload is measured, not modelled, and that is worth more than a benchmark. It leaves a support contract untouched, so the escalation path for storage incidents does not change in the same quarter as everything else. And it narrows the migration’s blast radius to one layer, which is a legitimate risk-management choice when the migration is already the biggest change of the year.

Now the other column, which the array-retention pitch tends to leave implicit.

The refresh clock keeps running. Retention is a deferral, and the deferred event is a full storage migration, done later, without the momentum, budget line, or executive attention that the platform migration currently has. Teams that defer often discover that the second project is harder to fund precisely because the first one already happened. The maintenance renewal keeps arriving, on its own schedule, at a price that typically rises as hardware ages out of its support tier. The fabric and its skills stay in the estate, which matters most in exactly the environments that are moving toward bare metal. And the operating model stays split: the array is provisioned by request, the new platform expects storage to be provisioned by declaration, and you will run both models at once for as long as retention lasts.

Table 1: The four array decisions available during a platform exit, and the condition that makes each one correct.

The split-estate row deserves a warning, because it is the row people choose when they cannot choose. Running the array for one tier and a new pool for the rest is a valid architecture and a bad accident. Chosen deliberately, with a named dependency and a date on which it is revisited, it is how careful teams de-risk a large migration. Arrived at by drift, it is how estates end up with two storage platforms, two skill sets, two support contracts, and no plan to converge, which costs more in operational attention than either endpoint would have. If you pick it, write down the dependency and the review date in the same document as the migration plan.

There is a related cost that shows up in the licence column rather than the hardware column, and it is worth naming while you are comparing paths. Some storage licensing scales with the cores you add, which means hardware density and consolidation quietly work against you. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. That is relevant to this decision because it makes the comparison a hardware and operations comparison rather than a licensing puzzle layered on top of one. If you want the licensing side of the exit modelled properly, the per-core cost analysis of vSphere and vSAN against an NVMe alternative goes through it in detail.

Not sure whether your array should come through the exit with you? If you are scoping a VMware exit and want the array decision modelled against your actual support dates, fabric, and workload profile before the migration plan is signed rather than after, that is a conversation worth having early. Talk to a storage architect

The fabric question, and the one thing that blocks bare metal

If the array stays, the fabric stays, and the fabric is where retention gets more interesting than the array itself.

Fibre Channel works. That is worth saying plainly, because the protocol comparison has been done to death and it usually ends in a verdict rather than a decision. An established FC fabric is low latency, well understood by the people who run it, and entirely capable of carrying your workload for another five years. The question is not whether it performs. It is who operates it in 2028, on what hardware, and for how many remaining consumers.

That question gets sharper as the consumer count falls. A fabric serving an entire virtualization estate is infrastructure. The same fabric serving two retained tiers is a dedicated network, with its own switches, its own licensing, its own firmware lifecycle, and its own zoning discipline, maintained for a shrinking population. The per-consumer cost of the fabric rises every time something moves off it, and nothing about that shows up in the array’s depreciation schedule.

There is one mechanism inside this that genuinely blocks plans rather than merely complicating them, and it is worth checking before you commit to a sequence: boot from SAN. In a vSphere estate, hosts booting from array LUNs is a normal and well-supported arrangement, with the HBA and the fabric doing the work and the hypervisor installed on a LUN rather than local media. Bare-metal Kubernetes nodes are a different proposition. The node’s own boot path, its provisioning workflow, and the lifecycle tooling you use to reimage nodes all have to account for it, and the answer is specific to your hardware, your HBAs, and your provisioning stack rather than general. Check it early. A plan that assumes nodes boot the way hosts did can survive design review and fail during the first reimage, which is the worst possible moment to discover it.

Table 2: What the fabric was doing on your behalf in vSphere, and who owns each part once the hypervisor is gone.

This is also where the Ethernet option becomes worth costing rather than debating. Carrying block storage over standard Ethernet with NVMe over TCP instead of a dedicated Fibre Channel fabric removes a network from the estate rather than replacing a protocol in it, which is the part that actually changes the operational arithmetic. For a team already consolidating onto Ethernet for everything else, that is frequently the strongest single argument in this entire decision, and it has nothing to do with benchmark numbers.

What simplyblock supplies, and what it does not

A note on scope, stated directly, because the rest of this article is only useful if this part is honest.

Simplyblock pools NVMe devices in commodity servers and presents logical volumes to consumers over NVMe/TCP or NVMe/RoCE, with thin provisioning, snapshots, replication, and erasure coding handled in software. Local NVMe is the performance recommendation and it is what a production cluster should be sized around.

The part worth knowing for this particular decision is that the backing devices do not have to be local NVMe. Simplyblock can take any whole Linux block device into its pool, which includes SAS and SATA behind an HBA, virtualized disks, cloud volumes, and LUNs an existing array presents to the storage nodes. That turns an array you already own into capacity underneath a modern storage layer: the erasure coding, snapshots, QoS, cross-cluster replication and NVMe/TCP presentation become simplyblock’s, while the disks you paid for keep earning. Two caveats belong in the same breath, because this is the row where vendors usually stop talking. Support for non-NVMe block devices is newer than the NVMe path and local NVMe remains the recommendation for production performance, so an array-backed pool is best understood as a transition and asset-sweating option rather than the shape you would design from scratch. And simplyblock formats the devices it takes, so this is not array virtualization in the sense of wrapping your existing LUNs and leaving the data where it is. The capacity comes across; the data still has to be migrated onto it.

What that means for this decision is that simplyblock can be the destination or the bridge, and the difference is which devices you point it at. Three properties matter in either role:

• It is the same product on either deployment model. Storage and compute can live on the same nodes, which is the hyperconverged arrangement most teams recognise from vSAN, or they can be separated so that each scales on its own axis. That choice is a deployment decision rather than a product decision, which matters during a migration because it can change once without changing vendors.
• It does not pick your platform for you. The same storage layer serves KubeVirt, OpenShift Virtualization, bare-metal Kubernetes, and containerised workloads. During a multi-year exit where the platform question may still be open, that is worth more than any individual feature, because it means the storage decision does not have to wait for the platform decision to finish.
• Capacity and compute scale independently. Adding capacity does not require adding compute, and the reverse holds too, which is the specific thing a fixed-configuration array cannot do and the reason the split-estate path so often becomes permanent.

For the wider architecture around it, including what else changes when the hypervisor stops owning the storage relationship, the storage layer in a private cloud after VMware covers the same ground one level up, and what actually expires with a perpetual VMware licence is the right place to start if your dates are still unclear.

The thing worth taking from all of this is smaller than a recommendation. Both of the answers you will be pitched are defensible, and which one is yours depends on two dates that you already have, in a contract and an asset register, and probably have not put on the same page. Put them there first. The architecture argument is much easier after that, and quite often it is already settled.

Questions and Answers

Can we leave VMware without replacing our storage array?

Often yes, and whether you should depends on two dates rather than on architecture. The array keeps presenting LUNs to whatever platform replaces the hypervisor, so retention is usually technically available. What decides it is how much support and headroom the array has left against when your migration window closes. With roughly two years of support remaining and comfortable headroom, deferring the storage decision is a reasonable way to narrow the migration’s blast radius. If the maintenance renewal or refresh date lands inside or just after the migration window, retention means opening the estate twice and paying for the same capacity through a transition you are already funding. Write both dates on one page before you take either vendor pitch seriously.

Does simplyblock work with our existing SAN?

Yes, in two different ways, and the distinction is worth getting right before you plan around it. Simplyblock can run alongside a retained array during a phased migration, with each serving its own tier. It can also take the array’s capacity directly into its pool, because its backing devices are not restricted to local NVMe: any whole Linux block device works, including LUNs the array presents to the storage nodes. In that arrangement the array becomes disks, and erasure coding, snapshots, QoS, replication and NVMe/TCP presentation are simplyblock’s job. Two honest limits. Support for non-NVMe devices is newer than the NVMe path and local NVMe is still the recommendation for production performance, so an array-backed pool suits a transition or an asset you are sweating rather than a greenfield design. And simplyblock formats the devices it takes in, so it is not wrapping your existing LUNs in place: the capacity is reused, the data is still migrated.

What happens to Fibre Channel and boot from SAN when we move to bare-metal Kubernetes?

Fibre Channel keeps working, and the real question is who operates it for how few remaining consumers. As workloads move off, the fabric’s switches, licensing, firmware lifecycle, and zoning discipline are maintained for a shrinking population, so its per-consumer cost rises without appearing anywhere in the array’s depreciation schedule. Boot from SAN needs specific attention: hosts booting from array LUNs is routine in vSphere, and bare-metal Kubernetes nodes need their boot path, provisioning workflow, and reimaging tooling checked against your actual HBAs and hardware. Verify it during design, because a plan that assumes nodes boot the way hosts did tends to fail on the first reimage.

Is keeping the array actually cheaper than replacing it?

It is cheaper at cutover and not necessarily cheaper across the transition, which is the distinction the retention pitch relies on. Retention defers capex and preserves a measured performance envelope and an untouched support path, all of which are real. Against that, the refresh clock keeps running, the maintenance renewal keeps arriving at a price that usually rises as hardware ages out of its support tier, the fabric and its specialist skills stay in the estate, and you run two provisioning models at once for as long as retention lasts. Compare total cost over the retention period against a single consolidated migration, and include the second project’s cost rather than assuming it will be easier to fund later.

Should we migrate the platform first or the storage first?

For most estates, the platform first and the storage on a date you have already chosen. The licensing change sets the deadline, so the platform move is the constrained piece, and attempting both layers in one cutover multiplies the risk at the worst moment. The failure mode to avoid is not sequencing, it is leaving the storage date unset: an array retained without a review date becomes a permanent second platform by drift rather than by decision. Choose the deployment model deliberately too, since storage and compute can be co-located or separated, and with simplyblock that choice can change later without changing vendors.