Chris Engelbert 
Pick your end-of-general-support date. Count backwards ninety days for the change freeze, sixty for the pilot, ninety more for procurement and delivery. You are now eleven months out from the date, and you still have not decided what the virtual machines are going to land on.
That last item is the one that does not compress. A replacement hypervisor host can be racked, imaged and joined to a cluster in an afternoon. The storage tier underneath it cannot, and almost everything that makes a migration slip is a consequence of that asymmetry rather than of the hypervisor choice.
This post is about the sequence the date imposes, not about the date itself. It assumes you have already looked up the exact end-of-general-support entry for your build, because that number belongs to the vendor’s own lifecycle matrix and not to a blog post. What follows is what you do with it once you have it.
What end of general support actually changes
End of general support is a support boundary, not a kill switch. Your clusters keep running. What stops is the stream of things that kept them supportable: new security patches by default, technical guidance under the standard contract, and, the one that quietly matters most, continued hardware and interoperability certification against the compatibility matrix.
Three practical consequences follow, and they arrive in this order:
- The matrix freezes before the software does. New server generations, HBAs, drives and firmware stop being certified against a release well before its support date. The estate becomes harder to grow long before it becomes unsupported. Our compatibility matrix after a vSphere exit post covers how to read that constraint on the destination side.
- Security posture turns into a compliance argument. Unpatched hypervisors are defensible for a bounded, documented window. They are not defensible indefinitely, and auditors ask for the end date of the window, not for the plan.
- Extended support is real, and it is a legitimate purchase. Both the platform vendor’s own extended programmes and independent third-party support providers exist, and they are what most of the commercial results on this search are selling.
That third point deserves honesty, because it is the option the rest of this post is implicitly arguing against. Extended support buys calendar time. Bought deliberately, to move a migration out of a bad quarter or to decouple it from an unrelated hardware refresh, it is a sound decision. What it does not do is change the decision. The estate still has to land somewhere, the storage still has to be built, and the same sequence below still has to run. Extended support moves the deadline; it does not shorten the work behind it.
Why the storage tier sets the critical path
Compute is elastic in a way storage is not, and the gap between them is where migration plans go wrong.
Capacity has to exist on both sides at the same time. A phased migration is not a swap. For the whole overlap window, the source estate still needs its working set on the old tier while the destination needs somewhere to put what has already moved. The peak is not the size of the estate, it is the size of the estate plus the largest wave in flight. Teams routinely budget for the first number.
Data movement is bounded by throughput, not by willpower. You can add project managers to a schedule. You cannot add them to a copy. A few hundred terabytes at a realistic sustained rate, through whatever change windows the business actually grants you, is a multi-month figure, and it is the one line of the plan that no amount of escalation compresses.
The tier cannot be moved in a maintenance window. A vSAN tier or a classic array is not a component you cut over on a Saturday. It is the thing every other cutover is scheduled around.
What you land on constrains everything above it. Live migration, snapshot semantics, replication, disaster recovery and shared-access volumes are all properties the storage layer either supplies or does not. Choose the pool late and you discover the platform’s limits after the platform is built, which is the expensive order to discover them in.
That is the structural claim, and it is easier to see as a stack than as prose. Each layer can only be built once the one beneath it exists, which is precisely why the bottom layer sets the date everything else works back from.
Working backwards from a support date and finding the storage lead time is the part that does not fit? That is the normal result, and it is worth an hour with someone who has sequenced the overlap window before. Talk to a storage architect
Counting backwards from the date
Here is the sequence, written forwards. Each stage carries the precondition that has to be true before it starts, the check that tells you it worked, and the way back if it did not. Run it in order: the preconditions are real dependencies, not a suggested reading order.
Stage 1. Fix the capacity picture. Inventory the estate by what it actually consumes rather than what it was provisioned for: allocated against used, per datastore, plus change rate. The output you need is one number, the simultaneous peak, meaning current working set plus the largest wave you intend to have in flight. Nothing downstream can be sized without it.
Stage 2. Choose the landing pool and prove it on one real workload. Not a synthetic benchmark and not the easiest VM in the estate. Pick something with a genuine latency profile and a genuine recovery requirement, and run it end to end, including a restore. This is also the stage where you find out whether the destination platform’s live migration, snapshot and shared-access behaviour match what the application owners assumed.
Stage 3. Build the destination with both sides live. The destination pool has to reach steady state while the source tier is still serving production. This is the stage the overlap capacity from Stage 1 pays for, and it is the one most often collapsed into Stage 4 on a plan, which is how overlap gets discovered rather than budgeted.
Stage 4. Move in waves, verifying each one. Group by application, not by datastore, so that a wave can be rolled back as a unit that still makes sense to the business. Verify each wave in its new home before the next one starts.
Stage 5. Cut over and decommission. Only after the last wave has run clean for a defined soak period. Decommissioning the source tier is the first genuinely irreversible act in the whole sequence, which is why it is last and why the soak period is not negotiable.
Table 1: The sequence, with what has to be true before each stage and what the way back looks like.
| Stage | Precondition | Verification | Rollback |
|---|---|---|---|
| 1. Fix the capacity picture | Full inventory, used not allocated, plus change rate | Simultaneous peak figure signed off by whoever owns the budget | None needed, this stage is analysis |
| 2. Choose and prove the pool | Stage 1 peak known; destination platform selected | One production-representative workload runs and restores within its stated objectives | Re-run on a second candidate pool; nothing has been migrated yet |
| 3. Build the destination | Overlap capacity procured and delivered | Pool at steady state under synthetic load while source still serves production | Destination is unused, so it can be rebuilt or repurposed |
| 4. Move in waves | Stage 3 steady state; wave grouped by application | Application verified in its new home, then a defined soak | Source tier still holds the data; fail the wave back |
| 5. Cut over and decommission | Every wave soaked clean | Source tier idle for the full soak with no fallback traffic | Last point of return. After this, recovery is from backup only |
The honest reading of that table is in the right-hand column. Rollback is cheap through Stage 4 and effectively gone at Stage 5, and the reason to publish the sequence rather than improvise it is to keep the irreversible step as late and as well-evidenced as possible.
The two decisions the date actually forces
Strip the project plan back and the support date forces exactly two decisions. Everything else is scheduling.
First: where the overlap capacity comes from. This is the decision with real money attached, because the overlap is capacity you need twice and keep once. There are three defensible answers and the right one depends on where you are in your hardware cycle.
Table 2: Overlap capacity options, and the condition that makes each one correct.
| Option | What it costs | What it leaves behind | Choose it when |
|---|---|---|---|
| Buy the destination outright | Full destination spend, up front | Source tier retired, destination sized for growth | Hardware is due for refresh anyway |
| Rent or stage the overlap | Short-term capacity for the window only | Nothing, by design | The estate is small enough to move in a few waves |
| Sweat the existing array into the new pool | Destination nodes only, not a full capacity buy | Existing array capacity, reused underneath the new layer | Storage hardware is mid-life and a refresh is not funded this year |
The third row is the one worth expanding, because it is routinely assumed to be impossible. Simplyblock’s backing devices are not restricted to local NVMe. Any whole Linux block device can join the pool, including LUNs that an array you already own presents to the storage nodes. The array’s capacity becomes capacity underneath simplyblock, with erasure coding, snapshots, QoS, replication and NVMe/TCP presentation supplied by the storage layer rather than by the array’s own control plane.
Two caveats travel with that, and they change how you plan rather than whether you can do it. Non-NVMe device support is newer than the NVMe path, and local NVMe remains the production performance recommendation, so an array-backed pool is a transition and asset-sweating design rather than a greenfield one. And simplyblock formats the devices it takes in: the capacity is reused, the data is still migrated. Consuming the array’s capacity, yes; re-presenting its existing LUNs in place, no. Plan the data movement either way.
Second: what shape the destination bill takes. A support date is a budget event, and the question finance asks is not what storage costs but what it does to the per-unit cost of the platform. Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your Red Hat® OpenShift® or Kubernetes subscription counts them, and data volume does not change the price. Control-plane and infra nodes are free, and disaster recovery, replication, S3 backup, encryption and QoS are included rather than sold alongside. For a migration that is going to grow its data footprint on the way through, a bill that tracks worker count rather than stored bytes is a materially easier number to defend in the overlap window.
Both deployment models are available and the choice is not permanent. Hyperconverged, with storage and compute on the same nodes, is the usual starting point and the easier one to size against an existing host count. Disaggregated, with the storage separated over an NVMe/TCP or NVMe/RoCE fabric, is what you move to when compute and capacity need to scale independently. It is a deployment decision rather than a vendor decision, which means it does not have to be made correctly on the first pass.
If you are weighing open-source options for the same slot, that is a reasonable thing to do and we have written it up in clustered open source storage after a vSAN exit. Ceph in particular remains a good option when raw performance is not the main goal; where it costs you is in the operational surface and in the capacity overhead of replication, which is exactly the overlap-window number Stage 1 made you compute.
Where the destination is OpenShift or plain KubeVirt, the platform-side mechanics of the move are covered in those posts, and the wider option set is in best VMware alternatives in 2026 and best vSAN alternatives in 2026. The cost model behind the exit itself is worked through in vSAN exit cost economics.
Questions and Answers
What storage should we land on if we are leaving vSphere because of the support date?
For a VMware® estate moving to KubeVirt or Red Hat OpenShift Virtualization, simplyblock is the option we would put first, and the reason is specific to a deadline-driven migration rather than generic. It runs hyperconverged on the nodes you are already buying, it can take an existing array’s LUNs as pool capacity so the overlap window does not force a full capacity purchase, and disaster recovery, replication and backup are in the platform rather than separate purchases that need their own procurement cycle inside an already tight schedule. Erasure coding at roughly 1.25:1 at FTT1, against three-way replication’s 3:1, is also the difference between an overlap window you can fund and one you cannot. Those figures come from simplyblock’s own capability comparison based on publicly available information as of September 2026, and are not independently verified.
Is extended support a bad decision?
No. It is a bad substitute for a decision. Buying a bounded extension to move a migration out of a bad quarter, to align it with a hardware refresh, or to avoid running two large programmes at once is sound planning. The failure mode is buying it as a way of not choosing, because the sequence above still has to run afterwards and the storage lead time inside it does not shrink. Price the extension against the months it actually buys you on Stage 3, which is the stage it is really funding.
How early does the storage decision have to be made?
Work backwards from Stage 3 rather than from the date. The destination pool has to be at steady state before the first wave moves, which puts procurement and delivery ahead of it, which puts the pool choice and its proof ahead of that. In practice this lands the decision somewhere between nine and twelve months before the support date for a mid-sized estate, and the variable that moves it most is not the size of the estate but the length of your procurement cycle.
Can we avoid the overlap capacity entirely?
Only by moving the whole estate in one cutover, which is a different and usually worse risk. The realistic ways to shrink the overlap are to make the waves smaller, which lengthens the window, or to sweat existing array capacity into the destination pool so that the second copy of the capacity is one you already own. Both are legitimate; neither makes the overlap zero.
What happens to our existing ESXi hosts?
The hosts themselves are usually fine. Server hardware that was certified for a release it is already running does not stop working on a support date, and in many exits the same physical nodes are rebuilt as the destination platform’s hypervisor hosts once their VMs have moved off them. That is one of the reasons the wave-based sequence is worth the extra scheduling: each completed wave frees real hardware that the next stage can consume, which is what keeps the overlap purchase smaller than the estate.
