Getting Off VMware After the Broadcom Acquisition: A Path That Worked
When Broadcom acquired VMware and restructured licensing into expensive subscription bundles, a regional client faced a sharp cost increase with no clear path forward. NetSafe assessed the virtual machine (VM) estate, selected a target platform, migrated the workloads with minimal downtime, and decommissioned VMware entirely, while modernizing backup and disaster recovery (DR) in the same project.
What Changed When Broadcom Acquired VMware?
For years, VMware’s vSphere and ESXi platform was the default choice for on-premises virtualization at small and mid-sized businesses. Licensing was perpetual or straightforward annual, the ecosystem was mature, and most managed service providers (MSPs), including NetSafe, knew it well.
When Broadcom completed its acquisition of VMware in 2023, the licensing model changed substantially. Broadcom moved customers off perpetual licenses and onto subscription bundles that packaged features many smaller organizations did not need or use. For a client already running a lean IT budget, the renewal math no longer worked. The new pricing was not a marginal increase; it was a structural reset that forced a decision.
The client’s options were straightforward to name but complex to evaluate: absorb the new subscription cost, migrate workloads to a Microsoft Hyper-V environment already supported by existing Windows Server licensing, move VMs to Proxmox Virtual Environment as a cost-sensitive on-premises alternative, or take the opportunity to migrate workloads to Microsoft Azure entirely. Each path had real trade-offs around capital cost, operational complexity, and long-term licensing exposure.
The client engaged NetSafe to assess the environment and recommend a path, then execute it. The goal was to exit VMware before the next renewal, without disrupting the workloads the business depends on.
How Did NetSafe Approach the Migration?
NetSafe’s approach followed the same principle it applies across its managed IT services engagements: assess the actual environment before recommending a platform. A VMware exit decision that is made on cost alone, without understanding the workload dependencies, network layout, and backup posture, creates risk during and after the migration. The assessment phase is where that risk is mapped and either mitigated or accepted consciously.
The VM estate review covered every virtual machine: what it ran, how it was sized, what it depended on, and whether the workload was a candidate for a straight lift-and-shift, a right-sizing, or a cloud move. For this client, the majority of workloads were Windows Server roles with no material cloud dependency, running inside an environment already licensed for Windows Server Datacenter. Microsoft Hyper-V was the right answer: no additional hypervisor licensing, familiar management tooling for the team, and a path that did not require retraining the client’s staff on a new platform.
The cloud migration option was evaluated and set aside for this engagement. Most workloads were not cloud-shaped: they were latency-sensitive internal services that would have required architectural changes to run well in Azure. The right platform is the one that fits the workload, not the one that fits the marketing narrative.
With the platform decision made, NetSafe scoped the migration sequence to minimize production downtime. Workloads were grouped by criticality and dependency. Non-critical VMs migrated first, validated, then production workloads followed under a maintenance window sized to the actual transfer time. Before any VM was cut over, its backup was verified on the new platform.
Migration Approach
How Was the Migration Sequenced?
The cutover ran in discrete stages, with each stage verified before the next began. The guiding constraint was that no business-critical workload should experience an unplanned outage during the transition.
| Stage | Workstream | Outcome |
|---|---|---|
| Assessment | VM estate inventory, sizing review, and dependency mapping | Full inventory of all virtual machines, workload dependencies identified, target sizing confirmed, migration groupings defined by criticality |
| Platform build | Hyper-V host provisioning and network configuration | Target Hyper-V environment provisioned on existing Windows Server Datacenter licenses; networking and storage validated before any migration began |
| Non-critical migration | Low-risk VMs migrated and validated first | Non-production and low-criticality workloads migrated, tested, and confirmed stable; process and tooling validated before production workloads moved |
| Production cutover | Business-critical VMs migrated under maintenance window | Remaining workloads migrated during a scheduled window sized to actual transfer time; each VM validated before the VMware copy was retired |
| DR modernization | Backup and disaster recovery (DR) rebuilt for the new platform | Backup configuration updated to cover Hyper-V VMs; recovery point objectives (RPOs) and recovery time objectives (RTOs) verified; DR tested before VMware decommission |
| VMware decommission | ESXi hosts and vCenter removed | VMware infrastructure powered down and removed after all workloads confirmed stable on Hyper-V; Broadcom licensing obligation eliminated |
What Did the Migration Deliver Beyond Removing the VMware Cost?
Exiting Broadcom’s licensing was the immediate trigger. What the client left the engagement with was more durable than a single cost line removed.
No exposure to future VMware pricing changes
Broadcom’s licensing model continues to evolve. Clients still on VMware are subject to whatever the next restructuring looks like. Running on Hyper-V under existing Windows Server Datacenter licensing removes that exposure entirely. The hypervisor cost is already paid for in the operating system license the client already owns.
Workloads kept running through the cutover
The migration was sequenced so that production services were never simultaneously down on both platforms. Every VM was validated on Hyper-V before the VMware copy was retired. The client’s staff and end users experienced the transition as a planned maintenance window, not a disruption.
Disaster recovery built for the new platform from day one
VMware migrations frequently leave the backup and disaster recovery configuration behind, pointed at the old platform. NetSafe scoped the DR rebuild as part of the same engagement. When VMware was decommissioned, the client had a verified, tested recovery configuration for the new environment, not a gap to fill later.
Licensing that fits the organization
The platform recommendation was grounded in what the client already owned and what their team already knew how to operate. Microsoft Hyper-V under Datacenter licensing is not the right answer for every VMware exit, but for a Microsoft-centric shop it is a well-understood path with no net-new licensing spend and no retraining burden.
A foundation for a broader infrastructure review
Migrating a VM estate surfaces the full picture of what the organization is running and why. Several workloads in this engagement were good candidates for a future move to Microsoft Azure when the timing is right. That roadmap, developed as part of NetSafe’s virtual CIO (vCIO) services, is documented and ready to act on without starting from scratch.
A repeatable playbook for other clients
The same assessment-to-decommission sequence NetSafe ran here applies to any organization facing the Broadcom licensing increase. The target platform changes based on the environment, Hyper-V for Microsoft shops, Proxmox Virtual Environment for cost-sensitive on-premises, Azure for cloud-ready workloads, but the process is consistent. If you are on VMware today, there is a clean path off it.
Frequently Asked Questions, VMware Migration and Hypervisor Alternatives
Do I have to move to the cloud to get off VMware?
No. Cloud migration is one of three options, not the default. For many organizations, the workloads running on VMware are internal services that are not well suited to a direct cloud lift: they have latency requirements, licensing considerations, or architecture patterns that make an on-premises hypervisor the better fit. Microsoft Hyper-V and Proxmox Virtual Environment are both proven on-premises alternatives. NetSafe’s cloud migration practice includes the assessment work to help you choose the right platform for each workload, not just the platform that is easiest to pitch.
How disruptive is a hypervisor migration?
Disruption is a function of planning, not inevitability. A migration that sequences non-critical workloads first, sizes maintenance windows to actual transfer times, and validates each VM before retiring the source copy can be executed with no unplanned downtime for business-critical services. The work is real; the risk is manageable when the engagement is structured to account for it.
What happens to our backup and DR configuration when we move hypervisors?
It needs to be rebuilt for the new platform. Backup agents, replication jobs, and recovery configurations that pointed at VMware VMs do not automatically transfer to Hyper-V or Proxmox. A migration that treats DR as an afterthought leaves the organization unprotected during and immediately after the cutover. NetSafe scopes the DR rebuild as part of the migration engagement and verifies recovery before VMware is decommissioned. You can read more about how NetSafe approaches this under its disaster recovery services.
What is Proxmox Virtual Environment, and when is it the right choice?
Proxmox Virtual Environment is an open-source hypervisor platform that supports both KVM-based VMs and container workloads. It has no hypervisor licensing cost and a strong community and commercial support ecosystem. It is a good fit for cost-sensitive on-premises environments where the team is comfortable with Linux administration and the workloads do not have Windows-native dependencies that make Hyper-V the natural choice. For organizations already running Windows Server Datacenter, Hyper-V is usually the lower-friction path. NetSafe evaluates both in the assessment phase before recommending one.
How long does a VMware migration take?
It depends on the size of the VM estate, the complexity of the dependencies, and the target platform. A small environment with a handful of VMs and clean networking can complete in days. A larger estate with interdependent workloads, custom storage configurations, and a DR rebuild layered in takes longer. NetSafe sizes the engagement after the assessment, not before, so the timeline reflects the actual environment rather than a guess.
Can NetSafe handle the migration if we are in the middle of a VMware renewal cycle?
Yes. The assessment can begin immediately, and the migration timeline can be scoped to your renewal date. If you are approaching a Broadcom renewal and want to understand your options before committing, that conversation starts with the assessment under NetSafe’s managed IT services practice. There is no obligation to proceed to migration from the assessment, but most clients find the picture it provides is exactly what they need to make the decision confidently.
Facing a Broadcom renewal? There is a clean path off VMware.
NetSafe can assess your VM estate, recommend the right target platform for your environment, and execute the migration with verified data continuity and DR in place before VMware is decommissioned. The engagement starts with the assessment. No platform decision required before we begin.
Or call us:
(704) 333-0404