VMware costs have changed. It doesn't always mean your platform should

5 min read
15 Oct, 2026
VMware costs have changed. It doesn't always mean your platform should
10:08

Changes to VMware's commercial model have given many organisations a good reason to review their virtualisation strategy. Broadcom has moved VMware offerings away from perpetual licensing towards subscription and term-based models, alongside significant changes to the VMware portfolio. For some organisations, the commercial impact has been substantial.

That makes reviewing the market sensible. It doesn't necessarily make migrating sensible. There is an important distinction.

A higher VMware renewal may be the trigger for a strategic review, but it shouldn't become the entire business case for changing platforms.

The better question is: What infrastructure platform will best support our organisation over the next three, five and ten years?

That question can produce a very different answer.

Start with the possibility that staying with VMware is the right decision.

This is sometimes missing from conversations about VMware alternatives. If an organisation has a stable environment, mature VMware skills, extensive integrations, specialist workloads and several years remaining on its infrastructure, replacing VMware simply to reduce one line of the IT budget could prove more expensive than staying.

The licence price is visible. The cost of changing everything around it often isn't.

Virtualisation is rarely just a hypervisor. Enterprise environments typically have dependencies across storage, networking, backup, disaster recovery, security, monitoring, automation, application certification and operational processes.
The more sophisticated the VMware environment, the more important those dependencies become.

So, the first option in any credible VMware review should be:

Stay where you are.

But test that option just as rigorously as every alternative.

Don't compare licence prices. Compare operating models.

A platform that costs substantially less to license can still cost more to operate.
Consider two hypothetical alternatives.

Platform A reduces annual software licensing by $300,000 but requires new hardware, retraining, replacement backup tooling and significant migration effort.

Platform B saves only $150,000 in annual licensing but reuses the existing hardware, fits existing operational skills and requires relatively little application remediation.

The apparently cheaper platform may not produce the better business case.

This is why we think organisations should model total cost of ownership rather than licence cost.

At a minimum that means considering:

  • Software licensing and subscriptions
  • Hardware acquisition and refresh cycles
  • Storage and networking changes
  • Migration tooling and professional services
  • Application remediation and testing
  • Backup and disaster recovery
  • Monitoring and observability
  • Cybersecurity
  • Training and recruitment
  • Vendor and third-party support
  • Operational effort
  • Business disruption during migration
  • The cost of operating two platforms during transition

These costs should then be modelled against realistic growth assumptions rather than today's infrastructure footprint.

A platform that looks attractive against today's 500 virtual machines may look quite different if the organisation expects to operate 800 in five years. Equally, an organisation expecting significant SaaS adoption or application containerisation may need fewer conventional VMs in five years, not more.

The future environment is what you're buying for. Not the current one.

Workload compatibility should come before platform preference

There is another trap.

Selecting the preferred platform and then determining how to migrate everything onto it.

We think the sequence should be reversed.

  1. Understand the workloads first.
  2. Which applications are straightforward Windows and Linux virtual machines?
  3. Which have unusual networking requirements?
  4. Which depend upon particular storage architectures?
  5. Which have specific backup or replication integrations?
  6. Which software vendors certify their applications only on particular platforms
  7. Which use hardware passthrough, GPUs or specialist devices?
  8. Which are approaching end of life anyway?
  9. And which applications should perhaps be modernised, containerised, moved to SaaS or retired rather than migrated?

This analysis can produce a much more nuanced strategy than "move 600 VMs from platform A to platform B."

It may ultimately produce several destinations.

There may not be one VMware replacement

The market now provides credible choices with very different strategic propositions.

Red Hat OpenShift Virtualization provides a different proposition. It allows virtual machines and containers to be operated on a common application platform and therefore becomes particularly interesting where virtualisation strategy intersects with application modernisation. Red Hat provides tooling to assess VMware workloads and identify migration compatibility and complexity before committing to a migration

Microsoft virtualisation technologies may make commercial and operational sense in strongly Microsoft-aligned estates.

Proxmox VE introduces another KVM-based alternative, particularly where organisations value open technologies and different licensing economics

Canonical OpenStack may make sense where the strategic objective extends beyond replacing a hypervisor towards establishing a private-cloud operating model.

Nutanix AHV can appeal to organisations seeking an integrated infrastructure and virtualisation operating model.

Public cloud may be appropriate for some workloads.

And VMware may remain appropriate for others.

That leads to an increasingly important possibility:

The answer may not be another strategic hypervisor.

An organisation might retain VMware for the workloads where its capabilities and ecosystem justify the cost, while moving suitable workloads elsewhere.

That is not necessarily architectural untidiness. Done deliberately, it can be a rational platform strategy.

Put cyber security and resilience into the decision from the beginning

A cheaper platform isn't cheaper if it weakens the organisation's ability to recover.

Any platform evaluation should therefore consider how the change affects:

  • Backup and recovery: Does the existing backup platform support the proposed environment at the required level?
  • Disaster recovery: Can existing RTO and RPO commitments still be achieved?
  • Ransomware resilience: What happens to immutability, isolation and recovery processes?
  • Security operations: How will the platform be patched, hardened, monitored and audited?
  • Operational resilience. What happens when something fails at 2am?

The last question deserves more attention than it often receives.

A technically capable platform with attractive licensing may be a poor enterprise choice if the organisation cannot obtain the skills, vendor escalation or local support necessary to operate it confidently.

Skills have a cost too

Moving from a platform an infrastructure team has operated for ten years to one they first encountered six months ago creates risk.

That doesn't mean don't move.

It means price the change properly.

Training is relatively easy to quantify.

The harder costs are reduced productivity during transition, dependency on scarce specialists, recruitment, changed operating procedures and the time required for teams to develop genuine operational experience.

This can materially change the comparison between platforms.

It is also why migration and operational strategy should be considered together. Getting workloads onto a new platform is only the beginning. Someone then has to operate it for the next five or ten years.

Model the decision over time

A one-year cost comparison can be actively misleading.

We think infrastructure platform decisions should be modelled across multiple horizons.

  • Year 1 exposes transition cost.
  • Year 3 begins to demonstrate whether the investment case is working.
  • Year 5 captures hardware refresh, growth and accumulated operational savings.
  • Year 10 forces a more strategic conversation about whether the proposed architecture is taking the organisation towards where it expects to be.

The model should also test what happens when the assumptions are wrong.

  • What happens if workloads grow 20% faster than forecast?
  • What happens if licensing increases?
  • What happens if hardware needs replacing earlier?
  • What happens if more applications move to cloud or SaaS?
  • What happens if the migration takes twice as long?

A business case that works only when every assumption is correct isn't a particularly robust business case.

The objective isn't to leave VMware

This is perhaps the most important point.

The objective of a VMware strategy shouldn't be to leave VMware.

It should be to determine the infrastructure platform strategy that best balances:

Cost. Risk. Resilience. Capability. Skills. Flexibility. And future business requirements.

For one organisation, that may mean migrating rapidly.

For another, it may mean moving selected workloads.

For another, it may mean negotiating a new VMware agreement and doing nothing for three years.

All three can be perfectly rational outcomes.

The important thing is being able to demonstrate why.

At OSS Group, this is the thinking behind our Infrastructure Platform Insight approach. We start with the customer's environment and business strategy, assess the realistic platform options, and model their financial, technical and operational consequences before recommending a direction.

Because when the decision could shape your infrastructure for the next decade, "which licence is cheapest?" is simply the wrong question.

Reach out to us at Infrastructure Team or call 0800-OSS-GRP, to gain clarity on your options today. 

OSS Group Latest Thinking Blog