VMware Backup: The Post-Broadcom Reality

Two years of customer calls

Since Broadcom closed the VMware acquisition in November 2023, I have been on dozens of calls with VMware customers trying to figure out what to do. The conversations have changed over those 24 months. In the first six months, the question was "how bad is this actually going to be?" Now the question is "what do we do about it?" The backup architecture decision sits inside that second question more than most teams realize. 

This piece is what I would tell a peer asking how to think about VMware data protection in the post-Broadcom environment. The Broadcom facts first, because they shape the choices. Then how backup decisions need to change. Then the technical fundamentals, which still matter. Then the three scenarios most teams I talk to fall into.

What 'post-Broadcom' actually means 

Broadcom completed the acquisition in November 2023. The first licensing changes came in December 2023, and the changes have continued through 2024, 2025, and into 2026. The cumulative effect is a VMware that operates under fundamentally different commercial rules than the one most enterprises adopted years ago. 

The changes that show up in every customer conversation: 

End of perpetual licensing. Perpetual licenses with annual support are gone. All new entitlements are subscription-only. Customers with perpetual licenses cannot renew them. Existing deployments continue to run, but expansion or renewal requires moving to subscription. 

Catalog consolidation from about 168 products to 4 bundles. The previous catalog has been collapsed into VMware Cloud Foundation (VCF), vSphere Foundation (VVF), vSphere Standard (VVS), and vSphere Essential Plus (VVEP). Customers who previously bought only specific components now buy broader bundles. 

Significant price increases. Customer-reported increases range from 8X to 15X over previous costs, depending on the prior configuration and which new bundle becomes the closest equivalent. The 72-core licensing minimum particularly hurts smaller deployments. 

Partner program reduction. The VMware Cloud Service Provider program shrunk from more than 4,500 authorized providers globally to a much smaller invite-only program centered on VCF. This affects route to market, especially for SMB and mid-market customers. 

Hyperscaler licensing changes. Effective November 1, 2025, customers using VMware on Azure VMware Solution or AWS Elastic VMware Service must bring their own portable VCF subscription purchased directly from Broadcom. The previous bundled licensing through hyperscalers is no longer available for new deployments. 

These are not predictions. They are facts as of early 2026. Reasonable customers can disagree on what to do about them. Most are evaluating their options. 

Why backup architecture matters more now than three years ago 

Before Broadcom, choosing a VMware backup tool was largely a technical decision. Which product handled vSphere snapshots best, integrated cleanly with vCenter, and recovered fastest. The architectural questions, how tightly was the backup tied to VMware specifically, could it operate against other hypervisors, mattered but rarely topped the evaluation list. 

Three implications now drive a different evaluation. 

Backup licensed alongside VMware inherits VMware's pricing trajectory. Backup tools bundled with VCF or sold as VMware-specific products are exposed to whatever Broadcom decides next. Independent backup platforms operating against vCenter APIs are not. 

Strategic flexibility now has measurable economic value. A backup platform that protects VMware today and Nutanix or AWS tomorrow gives the organization optionality. A backup platform that only works on VMware locks the customer into Broadcom's future pricing decisions, whatever they turn out to be. 

Migration tooling is no longer optional. Customers actively migrating workloads off VMware need backup that doubles as a migration platform. Same backup data, restored to a different hypervisor or cloud. Customers staying on VMware for now still benefit from having the option ready. 

Technical fundamentals that still matter 

The commercial environment changed. The technical requirements did not. Three foundations a VMware backup platform still has to handle correctly. 

Avoiding VM stun on hypervisor-level snapshots 

VM stun is the period during a VMware snapshot when the virtual machine becomes unresponsive while the hypervisor quiesces the filesystem, captures a snapshot, and writes in-memory state to disk. The VM is effectively inactive during the stun. With high I/O traffic, the stun can extend long enough to trigger primary server failover. The protection mechanism itself causing the downtime it is supposed to prevent. 

After the snapshot completes, a buffer log captures changes that occurred during the stun, and those changes must be applied back to the VM. Another time-consuming operation. As VMs have grown larger (multi-terabyte vDisks are now common), both quiescence periods and buffer log management have grown with them. The traditional VADP approach is honest about these tradeoffs but does not solve them. 

The architectural alternative is storage-level snapshots taken at the underlying storage layer rather than the hypervisor layer, capturing only granular updates with no recommit step required. On Nutanix-on-ESXi deployments, this works through native Nutanix snapshot APIs that work for both AHV and ESXi VMs. Backup performance unimpacted by VM size, no production VM downtime, no buffer log overhead. 

Application-aware protection, not just VM-level backup 

A VM-level backup is necessary but not sufficient. Critical applications running inside VMs (SQL Server, Oracle, Exchange, SAP) need application-aware backup that coordinates with the application's own consistency mechanisms (VSS Writers on Windows, application quiesce hooks on Linux). Without it, you have backup files but no guarantee of transactional consistency. 

Automated, config-free application discovery makes this scalable. The backup platform should identify which applications are running in which VMs and apply appropriate protection automatically, not require an administrator to specify the mapping for every VM. 

vCenter integration and zero-impact deployment 

Backup operations should integrate through vCenter APIs and inherit existing permissions, roles, and resource pool structures. The backup platform should run as software-only on the VMware cluster itself. No additional Windows Server licenses, no additional database licenses, no separate infrastructure for fast recovery. Any VMware backup requiring significant new infrastructure to deploy is adding cost that the Broadcom changes already pressed against. 

Three scenarios I see in customer conversations 

Most organizations evaluating VMware backup in 2026 fall into one of three scenarios. A backup platform worth choosing supports all three, because the customer's situation may evolve over the contract lifetime. 

A VMware-only backup product handles scenario 1 well, struggles with scenario 2, and works against the customer's interest in scenario 3. A hypervisor-agnostic backup platform handles all three through the same management plane. 

What to look for, post-Broadcom 

Six criteria separate VMware backup options that will hold up across the next five years from options optimized for the pre-Broadcom market. 

Independence from VMware's licensing. The backup vendor's commercial model and roadmap should not depend on Broadcom's decisions. Bundle inclusion or co-marketing is fine. Technical or commercial dependence is not. 

Hypervisor-agnostic architecture. Native support for VMware ESXi, Nutanix AHV, Hyper-V, and major public clouds. Migration between hypervisors through the same backup data should be a documented, supported capability, not a one-off services engagement. 

Storage-level snapshots to avoid VM stun. Hypervisor-level VADP snapshots are honest but limited. Storage-level integration with the underlying data platform (Nutanix, Pure, NetApp) provides impact-free protection for large or high-I/O VMs. 

Software-only deployment with no additional licensing. Backup requiring extra Windows Server licenses, SQL Server licenses, or backup-specific infrastructure adds cost on top of an already-strained budget. Pure software running on existing infrastructure should be the baseline. 

Application-aware backup and recovery. Auto-discovery of SQL Server, Oracle, Exchange, SAP, and other enterprise apps running inside VMs. Application-consistent backups. Granular recovery at file, application, or VM level. 

Ransomware readiness across hypervisors. WORM-capable backup storage, air-gapped backup copies, anomaly detection between backups, webhook integration with security tools. Ransomware does not respect hypervisor boundaries. Backup protection should not either. 

Common questions on VMware backup post-Broadcom 

Should I be exiting VMware because of the Broadcom changes? 

That is an organizational decision, not a backup decision. The right answer depends on existing workload investments, team expertise, application dependencies, and the actual price increase your organization is seeing. What backup architecture should give you is the option to make that decision later, by being independent of VMware's licensing and capable of supporting migration if you do decide to exit. The backup decision should not lock you into VMware or out of it. 

What does 'ESX-to-non-ESX cluster migration' actually mean? 

Using backup data captured from a VMware ESXi cluster to restore the same workloads onto a different hypervisor, most commonly Nutanix AHV but also public cloud destinations. The backup platform handles format conversion, configuration translation, and recovery orchestration. Done correctly, the workload comes up on the new hypervisor with application consistency preserved through the move. The same mechanism that supports cross-cloud DR, repurposed for permanent migration. 

If I'm staying on VMware, does Broadcom actually change what I should look for in backup? 

Yes, because backup is a multi-year commitment, and the right choice today should hold up across the next five years regardless of what Broadcom does next. Even if you are committed to VMware for the foreseeable future, choosing backup independent of VMware's commercial trajectory protects your data protection budget from inheriting VMware's pricing decisions. Optionality has option value even when you do not exercise the option. 

How long does VMware-to-Nutanix migration take with backup as the migration source? 

Technical migration of an individual workload is typically hours, not days. Restore the backup to the Nutanix cluster, validate the workload, cut over DNS and traffic. Full organizational migration is usually constrained by application dependencies, testing, and team capacity rather than the backup-and-restore mechanism. Most organizations execute these migrations over 12-36 months on a per-application or per-business-unit basis. 

Where to start 

If you are reevaluating VMware data protection, the most useful exercise is to identify which of the three scenarios you are in honestly. That clarity is often missing in customer conversations, partly because the answer changes over the year. Once you know which scenario you are in, the backup requirements become concrete. We are happy to walk through that conversation. Talk to your account team or start at hycu.com/trial.