The VMware Pricing Problem in 2026: Your Backup History Is the Hostage

What actually changed

Broadcom's own announcements and current product terms document three changes that materially affect renewal planning:

• New perpetual sales and SnS renewals ended. Broadcom stopped selling new perpetual licences and renewals of Support and Subscription for perpetual products. Broadcom also says customers may continue using perpetual licences they already purchased, so an existing perpetual entitlement should not be described as having disappeared.
• Products became bundles. Point products were folded into larger suites. If you ran vSphere and nothing else, the entry ticket now includes components you never deployed — priced in.
• Core minimums set the floor. Licensing is per core with minimum counts per CPU. Small hosts pay for cores they do not have; the floor, not your hardware, sizes the bill.

Public product terms do not establish any customer's price increase. The defensible comparison is your own renewal quote, estate inventory, contract terms and exit cost. Get the quote early enough to test alternatives rather than relying on industry anecdotes as a budget.

Why the renewal maths gets worse, not better

A short decision window constrains practical alternatives. If the first realistic exit plan begins only a few months before the contract lapses, there may not be time to validate applications, synchronize data and stage a controlled cutover. Every renewal completed without a tested alternative also resets the optionality clock: the skills, tooling and platform decisions needed for an exit remain deferred until the next commercial deadline.

The organisations that negotiate well do the opposite: they build a credible, tested exit path while they still intend to renew. Sometimes the exit gets exercised; more often the credible threat of it changes the quote.

The part nobody prices in: your backup history

Retention obligations don't reset because you migrated

Compliance requirements and internal policy define how far back each organisation must be able to restore. Those obligations attach to the data, not the hypervisor. Migrating a VM does not by itself remove the requirement to restore an older recovery point.

The zombie cluster

Conventional backup products store recovery points in formats restorable only into the platform that produced them. That can leave an exit plan with a quiet appendix: keep a minimal vSphere restore target operational, patched and supported for the retention period, with whatever entitlement the governing agreement requires. The cost and risk of that restore dependency belong in the exit comparison.

Why "restore then convert" fails at audit time

The workaround usually proposed is to restore old points into VMware and convert them on demand. At audit or incident time, that means a multi-hour, multi-tool pipeline — restore, convert, boot, hope — executed under the worst possible conditions, dependent on infrastructure you were trying to switch off. A recovery capability you cannot rehearse cheaply is not a capability; it is a story.

What backup-lineage portability looks like

The structural fix is to take the restore points out of the hypervisor's format entirely. When recovery points live in a platform-neutral repository and the restore path can convert on the way out, the question "can we still restore the old VMware backups?" stops depending on VMware existing. Yesterday's VMware backup restores onto CloudStack tomorrow — same lineage, same retention clock, no zombie cluster. This is precisely how Sendense treats backup history across platforms: the history travels with the workload, and the destination platform inherits protection on day one.

Sequencing the exit

None of this argues for a panicked migration. It argues for sequencing: prove restore portability with a controlled pilot, replicate a workload group second, and only then put a date against the estate — before the renewal deadline removes the planning margin. We maintain a full phase-by-phase checklist in the VMware exit solution, and the engineering-side pitfalls are covered in how to configure VMware-to-CloudStack replication with Sendense.

Primary sources

The licensing statements above are based on Broadcom's own announcement and published product terms, not secondary reports or estimated customer price multiples.

• Broadcom: VMware portfolio and licensing model changes
• VMware Cloud Foundation Specific Program Documentation, November 2025