Broadcom lists October 11, 2027 as the end of service for ESXi 8 and vCenter 8, with an optional two-year Extended Support period you can buy. That leaves four real options for the VMs running on it. You can renew and upgrade, pay to extend, move them to another hypervisor, or build new work on Kubernetes with KubeVirt and let the old VMs retire where they are. Most teams end up doing two of these at once.
What ends when general support ends?
General support is the window when the vendor ships patches and fixes for a release and takes your support calls for it. End of general support doesn't turn your hosts off. It stops the fixes, so every vulnerability found after that date is yours to manage.
For most security teams that is the real deadline. An unpatched hypervisor shows up as an audit finding long before it shows up as an outage, and the finding usually lands on someone who didn't pick the hypervisor.
Should you renew and upgrade?
For a lot of teams, yes. If the VMs on vSphere 8 run steady server work, your team knows the tooling and the renewal fits the budget, upgrading to a current release under a Broadcom subscription is the least disruptive path.
The cost is the bill, and you probably already know how that conversation goes. Alex wrote about it in You don't have to replace VMware. You have to survive the bill, so I won't repeat it here.
What does extending support buy you?
Extending buys you time. Broadcom sells that two-year Extended Support period for vSphere 8, and third-party support providers sell their own patch and break-fix coverage. Either one keeps you covered while you plan.
Neither one changes where the VMs run or what they cost to keep. Treat it as a bridge with a known end, and decide what's on the other side before you pay for it.
Should you move the VMs to another hypervisor?
Moving to another hypervisor, Proxmox for example, trades Broadcom's terms for someone else's and keeps the VM operating model your team already knows. It still means rebuilding or converting every VM, testing each one and running two stacks while you cut over.
That's a real project with a real end date. It makes sense when the estate is mostly long-lived server VMs and the main goal is a different bill.
Where do Kubernetes and KubeVirt fit?
KubeVirt runs VMs on a Kubernetes cluster next to containers. It suits teams that already run containers, or plan to, and want one place for both.
This is the option I'd look at first for new work. New VMs and new containers go on the cluster from day one, and the vSphere estate shrinks as old VMs reach the end of their life. You skip the single big cutover weekend.
Where does Orion fit?
Orion manages the VMs already on your vSphere and Proxmox hosts where they run, with no plugin to install, and brokers each user's connection to them. Those VMs sit in the same place as the new KubeVirt VMs and containers on the cluster Orion runs. Users connect over RustDesk or another remote desktop through the VM's port, whichever host the VM lives on.
You should know what Orion doesn't do before you talk to us. Orion doesn't convert, import or migrate VM images. It doesn't extend vSphere support either, so the patch clock on those hosts runs the same with Orion or without it. Moving a workload off vSphere means building it fresh on KubeVirt, from install media or from a golden image built there.
What Orion changes is the order you do things in. You can stop putting new VMs on vSphere now, keep the old ones running where they are, and retire them one at a time on your own schedule. Our VMs page covers how VMs run on Orion.
When is Orion the wrong answer?
If your vSphere estate is a few hundred server VMs that nobody launches or logs into, the decision in front of you is a hypervisor decision. Orion adds the least there. Pick the renewal or the move that fits your budget and your team.
If you need a tool that converts VM images, Orion isn't that tool either. Look at the conversion options for whichever hypervisor you are moving to.
What should you do this quarter?
Pull the list of VMs on vSphere 8 and sort it two ways, by who uses each VM and by when it would retire anyway. The VMs people log into every day are where self-service matters most. The ones due to retire before October 2027 may not need a plan at all.
Whatever is left over is your real decision, and it is usually a lot smaller than the full inventory. Put a date on it before the renewal quote puts one on it for you.
If you want to see your vSphere VMs and new KubeVirt workloads side by side on your own hardware, talk to us about a Proof of Value.
WRITTEN BY
Tony Como
Tony runs go-to-market at Juno, from first outreach to production deployment. He works across sales, partnerships, and operations to help technical teams move faster without adding infrastructure overhead.