VMware vSphere 8 end of support: renew on VCF 9 or migrate

Why vSphere 8 end of service forces a renew-or-migrate decision now

vSphere 8 reaches end of service on October 11, 2027, and the decision in front of you is whether to renew on VMware Cloud Foundation 9 or VMware vSphere Foundation 9 subscriptions or to plan a migration to an open-source platform before that date. Broadcom's knowledge base lists ESXi 8.x, vCenter Server 8.x, vSAN 8.x, NSX 4.x, HCX 4.x and VMware Cloud Foundation 5.2.x in the same end of service window, and after that date there is no technical support and no new patches. Broadcom recommends adopting VCF 9 or VVF 9, and it is the vendor's stated path, so the renewal option deserves a fair quote before you rule it in or out.

The timing matters because of how perpetual licenses behave. According to Broadcom's knowledge base, ESXi hosts and vCenter on perpetual licenses keep running after Support and Subscription expires, but downloads of new patches and major version upgrades require an active support contract. Broadcom also stated in December 2023 that perpetual licensing was ending and that customers would move to subscriptions at renewal. Confirm with your Broadcom account team which of your entitlements are perpetual, which are SnS, and what each renewal date commits you to, because a host that keeps running can still become one you cannot patch.

The open-source options fall into two groups. Proxmox VE, XCP-ng with Xen Orchestra and Harvester are like-for-like cluster platforms that replace hypervisor, management and, with the right storage design, much of the vSphere workflow. OpenNebula, Apache CloudStack and OpenStack add a cloud management layer for multi-tenant or self-service needs, and CloudStack can manage vSphere and KVM side by side during a phased move. Whichever you pick, a migration wave plan needs to finish well before October 11, 2027, so the comparison pages in this group are the next read.

What the end of service date requires from your plan

Five constraints shape the decision on VMware vSphere 8 end of support. Each one narrows the options, and together they set how much time a renewal or migration plan has before the end of service date.

October 11, 2027 end of service

ESXi 8.x, vCenter Server 8.x, vSAN 8.x, NSX 4.x and HCX 4.x all reach end of service on this date, and VMware Cloud Foundation 5.2.x does too. Broadcom's knowledge base is the authoritative source for the affected builds. Confirm with Broadcom which of your components and build numbers are in scope, since NSX and HCX often run on different lifecycles than the hypervisor.

No patches after end of service

After the end of service date, Broadcom states there is no technical support and no new patches for the affected products. Your hosts will keep booting and running, but any vulnerability found after that date stays open unless you have a compensating control or a migration already underway. Ask your security team to map which hosts sit on internet-facing or regulated segments, since those carry the most exposure.

Perpetual licenses lose patch downloads

Perpetual licenses keep ESXi hosts and vCenter running after Support and Subscription expires, but downloading new patches and major version upgrades requires an active support contract. A host that is still running is not automatically a supported host. Check whether your perpetual entitlements carry active SnS, because a lapsed contract blocks the security fixes you need before October 2027.

Per-core VVF or VCF at renewal

Broadcom sells many vSphere capabilities, including vSphere Enterprise Plus, vSAN, NSX and Site Recovery Manager, only inside VMware Cloud Foundation or VMware vSphere Foundation. Renewal means moving to a subscription bundle that Broadcom prices per core, and the scope of that bundle determines the cost. Request a quote that lists the core count, the minimum core entitlement and every component included, so you can compare it line by line with an open-source plan.

Migration waves must finish first

A migration to an open-source platform needs to finish before the end of service date, not start near it. Plan the waves backwards from October 11, 2027, leaving time for pilot workloads, rollback testing and the cutover of workloads that cannot be imported directly, such as VMs on vSAN-backed disks or with snapshots. Confirm your own change windows and staffing, since those set the real schedule more than any vendor date does.

Renewing on VCF 9 or VVF 9 versus migrating to open source

Renewing keeps the VMware stack, the vCenter workflows your teams know and the vendor support path. Broadcom recommends VCF 9 or VVF 9 as the successor to vSphere 8, and products such as vSphere Enterprise Plus, vSAN and NSX are now sold only inside those bundles. Perpetual hosts keep running after support expires, but new patches and major version upgrades require an active contract, so an unrenewed estate accumulates exposure over time.

What it keeps: the existing ESXi, vCenter and vSAN operating model and the skills your staff already hold.
What it changes: the licensing basis moves to subscriptions, and standalone products are replaced by bundles at renewal.
Main trade-off: the recurring subscription cost and vendor dependence continue for as long as the estate runs.
Timing: vSphere 8 reaches end of service on October 11, 2027, so the bundle, core count and upgrade schedule must be settled well before that date.

Ask for the bundle, core count, term and upgrade path in writing, and confirm which of your current hosts and add-ons the quote actually covers.

Which open-source platform fits which vSphere workload

This table compares Proxmox VE, XCP-ng with Xen Orchestra, Harvester, OpenNebula, Apache CloudStack and OpenStack against the needs that drive a vSphere 8 exit: ESXi import path, licensing, support, storage and known gaps. Use it to shortlist two or three platforms, then confirm each open item in a proof of concept on your own hardware.

Migration need	Proxmox VE	XCP-ng with Xen Orchestra
ESXi import path	Built-in import wizard in 8.2 and later reads ESXi and vCenter, tested from ESXi 6.5 to 8.0; OVF and VMDK import are fallbacks	Xen Orchestra V2V warm-migrates from ESXi 7 and later over HTTP; ESXi 6.x is not supported
Licensing	AGPL v3; all features in every tier; subscriptions are per socket per year and optional	Open-source hypervisor and Xen Orchestra; Vates support plans are per host, optional
Support model	Community tier has no tickets; paid tiers add ticket volume and response targets	Vates commercial subscriptions add SLAs; community support is available
Storage options	LVM, ZFS, iSCSI, NFS, CIFS, Ceph RBD and CephFS; vSAN-backed disks cannot be imported	Xen Orchestra reads VMFS, NFS or vSAN datastores during V2V; XOSTOR is a paid Vates add-on
Main gaps to confirm	Snapshot-heavy VMs import slowly; confirm encryption and vGPU needs in your environment	Confirm your ESXi build is in the supported range and that your backup jobs are rebuilt

A timeline that finishes migration before October 11, 2027

This sequence works backward from the October 11, 2027 end of service date so that every wave, rollback point and ESXi decommissioning step lands before Broadcom stops technical support and new patches for ESXi 8, vCenter 8, vSAN 8 and NSX 4. Each step names the output that must exist before the next one starts.

Inventory workloads and map dependencies
Export a complete list of hosts, clusters, VMs, datastores, port groups, vSAN policies, backup jobs and external integrations from vCenter, and record which VMs use snapshots, encryption, RDMs, or vSAN-backed disks. Owners for each application sign off on their VMs, licensing terms and maintenance windows. The step is done when every VM has a target platform, a wave assignment and a named owner, and when the team has confirmed which disks cannot be imported with the Proxmox VE wizard (vSAN-backed disks cannot).
Build a pilot cluster and test imports
Stand up a small Proxmox VE cluster on current hardware, using a release such as Proxmox VE 9.2 rather than 8.x, since Proxmox VE 8 on Debian 12 reached end of life in August 2026. Import a representative set of VMs covering Linux, Windows, large disks and snapshotted guests, and test the fallback paths documented by Proxmox (OVF import, qm disk import for VMDK files and Clonezilla). The step is done when each test VM boots, its network and disk mapping are verified, and the import times are recorded for planning.
Design storage, network and high availability
Decide on the storage backend (Ceph, an existing SAN over iSCSI or NFS, or local ZFS with replication) and size the network for migration traffic and cluster communication. For HA, plan at least three cluster nodes, shared storage for guests, redundant hardware and watchdog-based fencing, so that a failed node is reset before its guests restart elsewhere. The output is a signed design document covering storage pools, VLANs, fencing, and the vMotion-style placement rules the team will replace. Confirm these details with your hardware vendor and your Proxmox support provider before purchase.
Set up backup, restore and rollback
Deploy Proxmox Backup Server or your chosen backup target, rebuild backup jobs for the target platform, and run a restore test for each VM class in the pilot. Define the rollback path for each wave: the source VM stays on vSphere, unchanged and powered off only after the target has been accepted, and the team documents how to power it back on. The step is done when a full restore has been tested on the target and the rollback runbook has been rehearsed with the application owners.
Run wave-based cutovers
Migrate VMs in waves, starting with low-risk non-production systems and ending with business-critical workloads. Each wave follows the same sequence: freeze changes, import or convert the VM, verify the boot, network and application tests, switch DNS or load balancer pools, and keep the source for the agreed rollback window. The output for each wave is a signed cutover record listing the VMs moved, test results and any deviations. Track progress against the inventory so that no VM is left on the source platform without an owner.
Decommission ESXi hosts and close out
Once the last wave is accepted, remove VMs from vCenter, retire vSAN disk groups and disable the NSX components used by the migrated workloads. Wipe and reclaim ESXi hosts following your data destruction policy, and update the CMDB, asset register, backup catalog and license records. The step is done when no production workload depends on vCenter or ESXi, the decommissioning evidence is filed for audit, and the team has confirmed the date of the final license and support cancellation with Broadcom.

Questions buyers ask before migrating off vSphere 8

What drives the cost of renewing on VCF 9 or VVF 9 compared with migrating?

The renewal cost is a recurring per-core subscription, so it grows with every core you add, while migration cost is mostly one-time work plus an operations budget that continues after cutover. Broadcom's knowledge base recommends VCF 9 or VVF 9 for the vSphere 8 estate, so ask the Broadcom partner for a written quote per core count and per host. On the open-source side, Proxmox VE charges per CPU socket per year for optional support, and the software itself is free, so the recurring line items are support tiers, hardware, storage, backup and staff time. Ask for each cost component separately so the two options can be compared line by line, including the storage and backup tools you would still need.

How long does a vSphere to open-source migration take?

No fixed duration applies to every estate, because the time depends on the number of VMs, their size, snapshot history, storage type, network design and how many change windows the business allows. Proxmox documents that vSAN-backed disks cannot be imported directly and that VMs with snapshots import more slowly, so an estate with those features will take longer to plan and move. Ask for a written plan that lists waves, the owner of each wave, the rollback steps and the date that the last ESXi host leaves service, and make sure that date falls before the October 11, 2027 end of service for ESXi 8 and vCenter 8. Treat any timeline without a wave-by-wave breakdown as an estimate that needs verification.

Can our internal team migrate vSphere workloads without outside help?

A team can do it alone if it already has working skills in Linux administration, KVM or Xen, networking, storage such as Ceph or NFS, and automation with Ansible. The skills gap is usually in storage and high availability, because Proxmox HA needs at least three cluster nodes, shared storage and watchdog-based fencing, and a mistake there affects every guest. Be honest about the staff hours that the current vSphere team cannot give up during the move, and check whether the team has run a production cluster before. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your environment under a written, fixed scope, and it can work alongside your staff or take on defined parts of the project.

What does a paid support subscription add on Proxmox VE or XCP-ng?

Support subscriptions add support entitlements and access to the vendor's supported update path, and they do not change the software features. Proxmox VE sells Community at 120 euros per socket per year with no support tickets, Basic at 370 euros with 3 tickets and a 1 business day response, Standard at 550 euros with 10 tickets and a 4-hour response, and Premium at 1,100 euros with unlimited tickets and a 2-hour response. Vates lists Essential at $2,000 per year and Essential+ at $4,000 per year for up to 3 hosts, Pro at $1,000 per host per year with a 3-host minimum, and Enterprise at $1,800 per host per year with a 4-host minimum and 24/7 support, and its page describes SLAs as part of commercial support. Compare the stated response times and tickets, and ask each vendor to confirm what its SLA covers in writing.

What happens to perpetual vSphere hosts that are out of support?

Broadcom's knowledge base states that ESXi hosts and vCenter on perpetual licenses keep running after Support and Subscription expires, but downloads of new patches and major version upgrades require an active support contract. In practice this means the hosts still boot and run guests, while security fixes depend on whether you hold a current entitlement. For vSphere 8 specifically, Broadcom lists an end of service date of October 11, 2027, after which no technical support or new patches are provided. Plan for a patch and risk review for any host that falls out of support, and confirm with Broadcom which entitlement you hold, since perpetual licensing rules and renewal terms may differ by contract.

How does storage change when we leave vSAN?

Storage is one of the largest decisions in the move, because vSAN is sold as part of VCF or VVF and the replacement depends on your hardware and performance needs. Proxmox VE supports local storage on LVM, directories and ZFS, and network storage on iSCSI, NFS, CIFS, Ceph RBD and CephFS, so existing SAN or NFS storage can often stay in place during the first waves. Ceph requires its own sizing, network design and operations skills, and XOSTOR on XCP-ng is a Vates add-on priced per host per year. Before you commit, ask for a storage plan that covers node count, network bandwidth, data protection settings and how VMs on vSAN-backed disks will be moved.

Does DeployOpen issue compliance certifications for the new platform?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports, attestations and certifications. A migration changes the control environment, including access management, backup, logging, change control and network segmentation, so the evidence you collected for the vSphere estate may need to be regenerated for the new platform. Ask your auditor which controls and evidence they will need before cutover, and ask DeployOpen to scope the readiness work, deliverables and timeline in writing before work starts.

Evidence to keep for the renewal decision and the cutover

Whichever path you choose, the CIO, internal audit and regulators will ask for the same core records: what was decided, what was tested, what changed and what was destroyed. DeployOpen prepares this evidence inside your change and risk processes, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work.

Signed renewal or migration scope

Keep the signed decision that states the chosen path, the VCF 9 or VVF 9 subscription quantities or the open-source platform scope, the named owners and the target date before October 11, 2027. Record the end of service date for ESXi 8, vCenter 8, vSAN 8 and NSX 4 alongside the decision so the reason for the timeline is traceable. Confirm with Broadcom how your existing perpetual hosts and support entitlements are treated during the transition, and file that answer with the scope.

Import test results per VM

For each virtual machine, record the source configuration, the import method used, the boot result, the network mapping, the guest tools status and the application check performed by the owner. Note every exception, such as a VM on vSAN-backed disks or one with snapshots, and the fallback path that was used. These per-VM records show whether the migration preserved service behavior, and they are the first thing an assessor will sample.

Change records for each wave

Each migration wave needs a change record with its scope, approvers, the rollback criteria, the maintenance window, the actual outcome and any incidents raised. Link each wave to the import test results it depended on. Keep the record of who approved a forced power-off or a shutdown decision, since that approval is what separates a planned change from an unplanned outage in a review.

Backup and restore test records

Before a host is emptied, keep evidence that a backup of each migrated VM was taken and that a restore was tested on a separate target. Record the backup product, the job configuration, the restore date, the tester and the result. Restoring a sample of VMs from the new platform, not only from the old one, shows that the backups protect the workloads you actually run after the move.

Decommissioning record for ESXi hosts

When an ESXi host leaves production, record the date its VMs were confirmed moved, the removal of it from vCenter, the wiping or destruction of local and SAN storage according to your data handling policy, and the disposal or reuse of the hardware. Keep this record with the asset register and the license reconciliation. It proves that no workload or sensitive data remains on hardware that no longer has vendor support.

What changes for operations, backup and networking after the move

The first thing the operations team must rebuild is the management plane. vCenter currently holds inventory, roles, templates, distributed switches and the job schedules that operators rely on, and none of that moves automatically. On Proxmox VE, the cluster web interface takes over host, guest and storage administration, and the permission model is built from users, groups, roles and paths, which should be mapped one for one against the existing vSphere roles before any cutover. If the estate runs XCP-ng, Xen Orchestra plays this role for pools, and its RBAC model needs the same mapping exercise. Confirm the current role model, API authentication options and multi-cluster views against the Proxmox user management wiki or the Xen Orchestra documentation and your own environment, because automation that calls the vSphere API will need rewriting, not just repointing.

Backup is the item most likely to break silently. vSphere backup jobs, whether from a third-party product or a retained agent, are tied to vCenter and must be recreated against the new platform's backup target, retention rules and restore procedure. On Proxmox VE, Proxmox Backup Server is the natural target for scheduled guest backups, and it supports deduplicated, encrypted datastores, but the team should confirm which backup product their existing tooling integrates with and whether it supports the chosen hypervisor. Run a restore test for a representative Windows guest, a Linux guest and a database before any production VM is moved. Record the results as evidence, since assessors will ask how restore was verified after the platform changed.

Networking needs an explicit mapping exercise. Each vSphere port group, VLAN, teaming policy and distributed switch setting must have a counterpart in the target's bridges, VLAN-aware configuration or software-defined networking zones, and the firewall rules that protect those networks must be exported and rebuilt rather than assumed to carry over. Storage networks (iSCSI, NFS, or the replication traffic for Ceph) deserve their own mapping and an MTU check. Confirm the supported SDN features, firewall capabilities and any requirements for multicast or VXLAN against the current Proxmox VE or Xen Orchestra documentation for your release, and test failover paths before relying on them. Document the result as a network inventory that the security team can sign off.

How DeployOpen plans and runs a vSphere exit

DeployOpen approaches the vSphere 8 end of service date as a planning exercise with a written scope, whichever path the client chooses. We plan and implement self-hosted open-source platforms inside the client's own infrastructure, and we can also prepare the controls and evidence the client's own assessors will expect during the move.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We inventory ESXi hosts, vCenter, vSAN datastores, NSX segments and perpetual licensing status, so the written scope reflects the actual estate.
We agree which workloads move to the target platform and which remain on VCF or VVF until the wave plan is signed off.

How we build

We implement the chosen platform in the client's own data center or cloud account, including clustering, storage and network design.
We test migration waves against non-production copies, covering VM disks, network mapping, backup jobs and guest-level checks before cutover.
We harden the platform and document configuration against the client's internal baseline and any compliance framework in scope.

How we hand over

Handover includes runbooks for cutover, rollback, patching, backup restore and failover testing, written for the client's operations team.
We deliver configuration documentation and the evidence files the client needs for internal reviews and independent auditors, without issuing audit opinions ourselves.
Operators are trained on the day-to-day tasks the new platform requires, so knowledge stays inside the client's team.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
Retainers can cover platform upgrades timed to the vendor and Debian or distribution support windows, which the client should confirm for its chosen version.
Clients should ask for a written quote tied to the agreed scope, which sets out the fees, timelines and exclusions for each phase.