The answer is not to leave VMware as quickly as possible. Nor is it to renew by default.
For most established estates, the sensible route is to qualify workloads one by one, make the commercial deadlines visible, and keep the infrastructure supportable while the organisation moves at a pace its applications and recovery obligations can tolerate.
That often produces a mixed estate for longer than anybody first expected. It is not necessarily failure. It may be the controlled option.
The “VMware exodus” looks more like a traffic jam
In August 2026 I wrote on LinkedIn that the VMware exodus looked less like an exodus and more like a migration traffic jam.
CloudBolt's January 2026 research helps explain why. Its survey covered 302 enterprise IT decision-makers. It reported that 86% were actively reducing their VMware footprint, yet only 4% had completed a full migration away. CloudBolt's own conclusion was that most organisations were using phased risk reduction rather than a clean exit. That is a useful market signal, but it remains one vendor's survey sample rather than a census of every VMware customer. Read CloudBolt's research.
Broadcom's changes are also factual and important. In December 2023 it announced the end of new perpetual licence sales and renewals of Support and Subscription services for perpetual VMware offerings, with subscription and term licensing becoming the route forward. Existing perpetual licences did not simply disappear: Broadcom said customers could continue using licences they had purchased, while support remained governed by active contracts and product lifecycle. Read Broadcom's announcement.
Those commercial facts create a decision point. They do not remove the technical work required to move a production workload safely.
Start with six inventories, not a preferred replacement
The weakest migration plans start with a destination vendor. The stronger ones start with evidence.
1. Workloads
Record the application owner, business criticality, data sensitivity, performance profile, availability requirement and realistic change window for each workload.
“Runs on VMware” is not a migration unit. An application, its data, its operating system and its recovery process are.
2. Dependencies
Map networking, identity, DNS, backup, replication, monitoring, automation, storage, security tooling and vendor integrations. A virtual machine may be simple to move while the operating model around it is not.
3. Contracts and entitlements
Put renewal dates, subscription terms, support expiry, software rights and exit conditions on one timeline. A technically sensible sequence can become expensive if it collides with a renewal that nobody made visible.
4. Physical infrastructure
Record the server, storage and network models, serial numbers, locations, condition, warranty or support status, parts position and firmware dependencies beneath the virtual estate.
This matters because a software transition may take years while the hardware continues ageing underneath it.
5. Recovery
Test how each workload is restored today and how it will be protected during coexistence. Backup compatibility, recovery time and staff familiarity frequently matter more than the speed of the hypervisor conversion.
6. Skills and operational capacity
The people maintaining production are often the same people asked to assess alternatives, build pilots and migrate workloads. A plan that ignores this double load is not a plan; it is a hope.
Staying, moving and mixing can all be rational
A workload may stay on VMware because it is stable, supported and expensive to disturb. Another may move to a different virtualisation platform. A modern application might move to public cloud or containers. An old application may be retired or replaced with SaaS rather than migrated at all.
The decision should be explicit for each group:
- Stay: why is remaining the lowest-risk or best-value option, and when will that be reviewed?
- Move: what is the target, what must be proven in a pilot, and what is the rollback route?
- Retire or replace: who owns the business change and data retention?
- Mixed estate: which operating controls must be common across both platforms?
A mixed estate needs design. Without standardised identity, monitoring, backup, patching, incident ownership and configuration control, coexistence becomes a collection of exceptions that consumes the very capacity needed to finish the migration.
Product lifecycle is part of the decision
Broadcom states that vSphere ESXi and vCenter 7.0 reached End of General Support on 2 October 2025 and recommends upgrading to version 8.0 or later to maintain the full level of Support and Subscription services. The exact product, edition and entitlement still need to be checked against Broadcom's current lifecycle information. Read the Broadcom lifecycle notice.
That date should not be used as a generic claim that every VMware environment is unsupported. It should trigger an asset- and version-level check:
- Which ESXi and vCenter versions are installed?
- What support and software entitlements are active?
- Which hardware is certified for the intended upgrade?
- Which applications, backup products and integrations support the target version?
- Is the safest route to upgrade first, migrate first, or isolate and retire the workload?
Where third-party maintenance can help — and where it cannot
Third-party maintenance can provide a defined hardware support route for assessed servers, storage and networking after an OEM warranty or support term, subject to parts, skills, geography and the contracted service level.
During a long VMware programme, that may help an organisation:
- keep suitable physical infrastructure covered while workloads are qualified;
- avoid forcing a hardware refresh and a platform migration into the same change window;
- position spares against the real estate and site risk;
- create a controlled bridge to a planned retirement or replacement date; and
- place several hardware vendors under a coherent support model.
It is equally important to state what independent hardware maintenance does not automatically provide. It does not replace VMware software support, subscription rights, patches, Broadcom engineering escalation, OEM firmware entitlement or application-vendor certification. Those boundaries must be documented rather than blurred.
The right answer may therefore be OEM software support with independent hardware maintenance, full OEM cover for selected systems, customer-held spares for others, or a faster refresh where the technical risk justifies it.
A practical 90-day decision window
Days 1–30: make exposure visible
Build the workload, dependency, contract and asset inventories. Identify the next renewal and lifecycle deadlines. Stop placing net-new workloads on the incumbent platform by default unless there is an approved reason.
Days 31–60: test representative workloads
Choose a small set that represents the awkward parts of the estate, not only the easy demonstration cases. Test backup, recovery, monitoring, performance, security controls and operational ownership as well as conversion.
Days 61–90: commit to a sequence
Group workloads into stay, migrate, retire and investigate. Price the coexistence period. Decide which physical assets need OEM support, assessed independent maintenance, spares or replacement. Give every group a review date and an accountable owner.
How Myrmekes can help
Myrmekes helps IT teams scope multi-vendor infrastructure support, engineering requirements and hardware lifecycle decisions. UK delivery is provided through Cantel's engineering network; exact vendor, asset, location, parts and service-level coverage is confirmed for each engagement.
We do not need a polished migration strategy to start a useful conversation. Bring the asset list, sites, current cover dates and the constraints that are holding up the next step. We can help separate the physical infrastructure support questions from the software, licensing and application decisions that must remain with the appropriate owners.
- Review Myrmekes capabilities
- Compare support-contract options
- Read the third-party maintenance procurement guide
- Search Dell EMC lifecycle dates where relevant to the estate
- Discuss the estate
Sources
- Duncan Brown's original LinkedIn post, 14 August 2026
- CloudBolt: The VMware Decision Window, 18 February 2026
- Broadcom: VMware portfolio and licensing changes
- Broadcom KB: vSphere 7.0 End of General Support
Optional FAQ
Does third-party maintenance replace VMware support?
No. It may cover assessed physical hardware under a defined contract. VMware software entitlement, patches, licensing and vendor escalation remain separate unless an authorised provider expressly includes them.
Must every VMware workload move to the same destination?
No. Workloads can remain, move to different platforms, be replaced or be retired. The important point is to make the decision and operating model explicit for each group.
What should be checked before extending the underlying hardware?
Model and serial data, condition, capacity, parts, redundancy, firmware and software dependencies, site access, business criticality, required restoration time and the planned exit date.
Talk through the migration constraint
Bring the estate, renewal dates and practical constraints. We will help separate the hardware-support questions from the software, licensing and application decisions.
Send us the estate and migration constraint.