VMware licensing costs going up? Five points for evaluating alternatives

That renewal quote on your desk, signing or not signing shouldn't be a gut call. This article doesn't push any brand. It just sets out the five things most often overlooked when evaluating alternatives.

After Broadcom acquired VMware, its licensing model changed in several ways: perpetual licenses moved to a subscription model, pricing is now based on core count with a minimum purchase threshold per host, and modules that used to be sold separately were bundled into packages (source: market reporting). Go by the actual terms on the quote in front of you. The real question isn't "is VMware good"; it's what your data center budget will look like over the next three to five years if you sign this quote.

First, take stock of your current contract

Before comparing any alternative, lay out your own baseline:

  • How much time is left before expiry. With less than six months left, don't force a switch; negotiate a renewal buffer to buy time instead. With a year or more left, you have room for a phased migration.
  • Which license you currently hold. Which package, which modules it includes, what unit it's priced by, and the minimum core count per host.
  • Which features you actually use. This is the one most often missed, and the most critical. It's common to pay for the full license while only using VMs, live migration, and high availability. Putting "what you bought" side by side with "what you use" is the real starting point for the evaluation.

Point one: it's not just "switch" or "don't switch"

Most people frame the question from the start as "renew everything" or "move everything," which turns the evaluation into a gamble. There is a lot of middle ground. You can switch only your disaster recovery (DR) site - the backup environment that takes over if the production data center fails - while leaving production untouched; switch only your test and development environment; or put new projects straight on the new platform and let the old environment phase out naturally. The budget stays small, the risk stays manageable, and the team has time to learn the new platform first.

Point two: the real cost is more than the license fee

Comparing license fees alone will always distort the picture. Use TCO (Total Cost of Ownership, adding up everything you'll spend over three to five years) instead, and include at least:

  • License or subscription fees: calculate three to five years for both paths, not just the first year.
  • Hardware: whether existing x86 servers can be reused, and whether you need to add memory or drives.
  • Migration labor: how many VMs, how much downtime is acceptable, how many weekend maintenance windows you'll need.
  • Training and rebuilding know-how: existing scripts, monitoring items, and backup schedules all need to be redone, and this is often left out of the count.
  • Risk buffer: set aside extra time and budget for when things don't go according to plan.
Calculate both sides: staying put has a cost over three to five years too.

Point three: how well the migration tool works matters more than the feature list

Anyone can write an attractive feature list; what really determines whether a project goes smoothly is the migration tool. Ask directly: does it support live migration (without shutting down the VM)? Does it need an extra agent installed on the source side? Can a failure roll back safely? Do network settings, snapshots, and disk formats carry over? The most reliable approach is to actually migrate a few VMs during the POC (Proof of Concept) stage, deliberately picking the messiest one. If that one moves, the path is viable.

Point four: think about backup and disaster recovery together

Backup is often treated as a separate project, but it's the line item most likely to flip the whole evaluation. In your current environment it's usually a separate license. Many alternative platforms now build snapshots, backup, and remote replication into the platform itself, including immutable snapshots that stop ransomware from encrypting the backups along with everything else. Ask clearly whether the built-in backup is good enough, whether you can restore a single file, whether your existing backup software supports the new platform, and whether RPO/RTO (the tolerable amount of data loss and downtime) can be met. Fold the backup license into the TCO and run the comparison again, the conclusion often changes.

Point five: supply chain and long-term support

A platform you'll run for five or ten years can't be judged on today's feature list alone:

  • The vendor's size and staying power: ask about years in business, funding structure, and how transparent its public disclosures are, and request a written explanation.
  • Where the company is incorporated and where the technology comes from: which country it's registered in and where its R&D team originates. Government bodies, defense supply chains, and some foreign subsidiaries in Taiwan have origin-review rules that directly determine which options are even on the table.
  • Support path in Taiwan: who answers the phone when something goes wrong, whether there's Traditional Chinese documentation and engineers based in Taiwan, and who the vendor's authorized channel and support contact are in Taiwan.
  • Release cadence and support lifespan: request the published release cadence and end-of-support dates, and write them into a contract appendix. Don't rely on verbal roadmap promises.

A practical way to get started

  1. Inventory the contract: list expiry date, package contents, and modules actually in use in one table.
  2. Run a TCO estimate: staying and switching, using the same format, each calculated over three to five years.
  3. Run a POC: use a test environment to actually migrate a few VMs, including the most troublesome one.
  4. Switch a small piece first: the DR site or the test/dev environment, leaving production untouched.
  5. Observe for one to two quarters: confirm performance, backup, and operations hold up before touching production.

The biggest value of this approach is removing the time pressure of "we have no choice but to switch"; how much money you save becomes secondary. With a TCO you can point to, a completed POC report, and a small new platform already running, your position in renewal negotiations changes completely.

← Back to Insights

What a licensing health check and TCO estimate include

Four things you can bring straight into a meeting, not a slide deck.

Contract and usage inventory
Compares license entitlements against modules actually enabled, to find what you're paying for but not using.
TCO estimate
Renewal and replacement, in the same format, each calculated over three to five years, including migration labor and training.
POC hands-on test
Actually migrate a few VMs in a test environment, measuring migration time and post-migration performance.
Phased rollout recommendation
A roadmap starting from the DR site or test environment, including the scope of annual maintenance (business-hours support).
"If the numbers show that renewing first is the better deal, the assessment report will say so."
- GN-AI Information Consulting, Technical Team

Related reading: understand what hyperconverged infrastructure is first, then see which path fits whom.

Book a licensing health check and TCO estimate See our services

Ask about a licensing health check and TCO estimate

Leave your contact details and a description of your needs, and an engineer will get in touch to help assess architecture planning, deployment approach, and annual maintenance scope.

Send an enquiry
LINE Ask us on LINE