Strategy 01 · Retain
In plain languageKeep the workload as it is.
VMware exit is not a platform swap. It is a workload placement decision.
Broadcom changed the renewal conversation. The reflex is to compare replacement platforms — Hyper-V, Nutanix, Azure VMs, Azure Local, OpenShift or Proxmox. That reflex skips the work that determines the outcome.
A VMware exit should start workload by workload: what still matters, what can retire, what must move together, what it actually consumes, what recovery target it needs, and what operating model the destination will require. The platform decision should follow that work, not replace it.
Renewal trigger / workload analysis / placement map
TriggerBroadcom renewal
MethodWorkload-led, not platform-led
StrategiesEight CAF workload strategies
ReviewFour-phase exit review
Why the reflex is incomplete
Three questions that explain where most VMware exits go wrong
The Broadcom trigger is real. The reflex it produces is incomplete. Most exits that run into trouble do so because one of these three questions was skipped before a platform shortlist was drawn up.
01
Did the plan start with a replacement platform, or with the workloads?
A platform-swap mindset assumes every VMware VM should keep being a VM, somewhere else. That assumption is wrong often enough that the work has to start with the estate, not the hypervisor shortlist.
Failure modePlatform-first reflex
02
Was the destination sized from performance data, or from nominal VM configurations?
A VM provisioned with 16 vCPUs and 64 GB of RAM that has consistently used 4 vCPUs and 12 GB is not a 16-vCPU workload. Sizing the target from the source nominal configuration produces oversized targets, inflated cost estimates, and migration designs that look more expensive than they need to be.
Failure modeNominal sizing
03
Were dependencies mapped, or treated as optional?
Servers do not exist in isolation. Application components have dependencies that determine what must move together, what can be retired, and what would create a surprise outage if migrated alone. Skipping dependency analysis is how organisations end up with broken services on day one.
Failure modeUnmapped dependencies
The expensive mistake
Buyers who start with replacement platforms start in the wrong place.
Platform swap
- Starts with a hypervisor shortlist
- Assumes every VM stays a VM
- Sizing nominal VM configurations
- Dependencies treated as optional
Workload placement
- Starts with the estate as it runs
- Eight strategies; several drop the VM
- Sizing performance data
- Dependencies mapped before anything moves
The workload strategies
Eight workload strategies — and several do not involve preserving the VM at all.
For most Australian organisations with VMware estates, a routine annual renewal has turned into a strategic decision: continue with the new VMware footprint at the new commercial terms, or reduce, partially exit, or fully exit the platform. Many buyers jump straight into a replacement-platform shortlist. Microsoft's Cloud Adoption Framework instead formalises eight workload strategies — most estates end up using three or four in combination, and very few strong exit plans rely only on rehosting.
Strategy 02 · Retire
In plain languageRemove the workload because the business value no longer justifies the operational cost.
Strategy 03 · Rehost
In plain languageMove the VM to a new platform with no application changes.
Strategy 04 · Replatform
In plain languageMove onto a managed service that reduces infrastructure burden.
Strategy 05 · Refactor
In plain languageRework the application for cloud-native operation.
Strategy 06 · Rearchitect
In plain languageRedesign for a fundamentally different design.
Strategy 07 · Rebuild
In plain languageStart from scratch where the existing application can no longer carry forward.
Strategy 08 · Replace
In plain languageAdopt a SaaS alternative that simplifies the operating model entirely.
The trigger is real. After Broadcom's acquisition of VMware, the portfolio simplified: VMware Cloud Foundation and vSphere Foundation became the primary subscription offers, many standalone products moved to end of availability, and existing customers had to align to the updated portfolio at renewal. Industry groups and EU regulators began examining complaints about rebundling, perpetual-licence treatment and price increases. See Broadcom VMware renewal for the commercial detail behind the trigger.
The workload-led method
The questions to answer before any destination is considered.
Each workload deserves a deliberate decision rather than a default. Before the platform conversation begins, a workload-led exit review answers, for every workload in the estate: what still matters, what can retire, what must move together, what it actually consumes, what recovery target it needs, what latency it can tolerate, and what operating model the destination will require. Most workloads end up with a clear answer within a few hours of focused work — the estate-wide picture takes longer, but the per-workload thinking is not the bottleneck. The full per-workload framework sits on VMware workload placement, and the wider stay, reduce, stage, bridge or exit decision on VMware exit strategy.
Most exits end up using three or four of the five destinations. None is the default, none is wrong, and the mix depends on the estate rather than a vendor preference.
Five common destinations
01Modernised on-premises infrastructure
02Azure
03Azure Local
04Managed services or SaaS
05Retirement or replacement
The diagnostic frame
Four phases decide what gets done first.
A VMware Exit Review is not a vendor pitch and not a hypervisor recommendation. It is a workload-led assessment that produces a placement map, a sequenced migration plan and a day-two operating-model design — and the platform decisions sit inside that, downstream of the workload analysis.
The four phases are sequential; each one's output feeds the next. Skipping or compressing any of them is how exit projects end up over budget, behind schedule, or in production with infrastructure that does less than what it replaced.
Review
Estate and workload analysis
What is actually running, what each workload consumes from performance data, and which workloads still matter, can retire, or must move together.
Dependency and recovery mapping
What depends on what, what must move as a group, and what recovery target and latency tolerance each workload needs.
Placement and platform selection
The destination mix — on-premises, Azure, Azure Local, managed service, retire or replace — chosen per workload from the evidence, not from a vendor preference.
Sequenced migration and day-two design
The order of change, rollback and coexistence, and the operating model the business can actually run after the move.
The Inlight IT view
Make platform decisions from evidence, not renewal pressure.
Broadcom has created a real commercial trigger, but VMware renewal pressure does not automatically answer the infrastructure question. The wrong move is to turn the renewal into a hypervisor bake-off and assume every workload should remain a VM somewhere else. The point is not to avoid platform decisions — it is to make them from evidence. A useful VMware Exit Review produces a workload placement map, sequenced migration plan, recovery design and day-two operating model; once those are visible, the platform choices become clearer, cheaper and less risky.
VMware exit is not a platform swap. It is a workload placement decision. The platform should be the output, not the starting point.
01
Start with the estate, not the shortlist
02
Size from performance data
03
Map dependencies before anything moves
04
Design day two before the migration
From insight to engagement
A workload-led VMware exit, delivered and then operated as part of managed services.
The review starts with the estate as it actually runs — which workloads still matter, which can retire, which must move together, what they really consume, what recovery target they need, what latency they can tolerate, and what support model the business can operate after the move. That work usually produces a mixed answer, and the output is a workload placement map, a sequenced migration plan, a recovery design and a day-two operating model — produced before any platform decision is made. Inlight IT runs that review and operates the resulting infrastructure as part of cyber-first managed services for Australian SME and mid-market businesses.
Infrastructure Refresh
The commercial home for a workload-led VMware exit: the review, the placement map, the sequenced migration and the day-two operating model.
Best whenWorkloads stay on modernised on-premises infrastructure or Azure Local, or the exit spans a mixed estate.
Explore Infrastructure Refresh Managed Cloud & Migration
Cloud-bound workloads planned and moved with the same workload-led method.
Best whenThe placement map sends workloads to Azure or to managed services.
Explore Managed Cloud & Migration Infrastructure Refresh
Choose the workload path before the platform.
Assess workload placement, dependencies and recovery requirements before committing to a platform.
Explore Infrastructure Refresh