VMware after Broadcom: a practical migration guide for Indian IT teams

Many IT teams in India have opened a VMware renewal quote in the last two years and gone quiet for a while. The usual reaction is either to pay and say nothing, or to announce that everything is moving off VMware by next year. Both are expensive mistakes. A renewal date is a deadline for a decision, not for a migration.

This guide is for teams running vSphere estates, from a few hosts in a server room to a few hundred in a colocation hall. It covers what changed, how to decide workload by workload, and what tends to break when you move. It is engineering guidance, not licensing advice: confirm your entitlements with Broadcom or an authorised partner.

What changed

Broadcom completed its acquisition of VMware in November 2023 and reshaped how the software is sold. Perpetual licences were abolished by spring 2024; VMware is now sold as subscriptions, bundled mainly into VMware Cloud Foundation and VMware vSphere Foundation, and licensed per processor core. Existing perpetual licences keep running, but support and new versions come through a subscription.

From 10 April 2025, according to reporting by the German technology publication heise, the minimum purchase rose from 16 cores to 72 cores, for new licences and renewals alike. For a small estate that changes everything: two small hosts with one 8-core processor each, 16 physical cores in total, would still be billed for 72.

Broadcom also changed how VMware is sold through hyperscale clouds. Hyperscalers can no longer sell VMware subscriptions to users of their hosted VMware services; customers buy directly from Broadcom and use licence portability.

What the analysts expect

Speaking at Gartner's symposium in Australia in September 2025, Gartner research vice-president Julia Palmer said that more than a third of workloads currently running under VMware will run on another platform by 2028. She also said a full migration takes three years or more, and advised against moving everything: assess which applications are ready to be re-platformed, and move those. That selective work, she said, can take up to a year.

A renewal date is a deadline for a decision, not for a migration.

Step 1: know exactly what you have

Before any negotiation or migration, build an accurate inventory: hosts, processors and cores per host, the VMs on each, which VMware features each workload actually uses (vSAN, NSX, distributed switches, Site Recovery Manager), and the renewal date. Two things usually fall out of this. First, a surprising share of VMs are idle or forgotten and can be retired. Second, consolidating onto fewer, denser hosts can cut the cores you license, as long as you stay above the purchase minimum.

Step 2: sort every workload into four groups

1. Keep on VMware. Large, complex or vendor-certified workloads, anything relying heavily on NSX micro-segmentation or vSAN, and systems you cannot afford to touch before an audit or a peak season. Keeping some workloads is a valid outcome.

2. Move to another hypervisor. Standard Linux and Windows server VMs with no deep dependence on VMware features. These are the bulk of most estates and the easiest to move.

3. Move to cloud or SaaS. Workloads that were going to be modernised anyway: email, file shares, some line-of-business applications.

4. Retire. The idle and duplicate VMs the inventory found. Retiring is the cheapest migration there is.

Step 3: choose the destination for each group

There is no single replacement, and the right answer depends on your skills, hardware and support expectations. In broad terms: Proxmox VE (open-source KVM with optional paid support) suits smaller clusters and teams comfortable with Linux. Nutanix AHV suits teams that want a supported hyper-converged platform, subject to its hardware compatibility list. Microsoft Hyper-V, or Azure Local, suits Windows-heavy estates already licensed for Windows Server Datacenter. Red Hat OpenShift Virtualization suits teams moving towards containers, running VMs and Kubernetes side by side. Whatever you choose, run a pilot on your own hardware before you commit.

Step 4: what breaks when you move

Most migrations fail on the surroundings, not on the VMs. Check each of these on the target platform before the first production move.

Drivers and guest tools. VMware Tools must be replaced by the target platform's drivers (for KVM-based platforms, virtio). Windows VMs in particular need the right storage and network drivers installed before cut-over, or they will not boot.

Backup and DR. Your backup software may protect VMware through its APIs and not support the new hypervisor in the same way. Confirm support, then restore-test on the new platform. Replace any Site Recovery Manager runbooks with the target's replication and failover, and drill them.

Networking and security. Distributed switches and NSX rules do not convert automatically. Map VLANs, firewall rules and micro-segmentation explicitly, and plan for MAC and IP changes.

Licensing beyond VMware. Windows Server is licensed by the physical cores of the host it runs on, so moving VMs between hosts can change what you owe Microsoft. Check application vendors' support statements for the new hypervisor too.

Monitoring and logs. Point monitoring at the new platform from day one, and make sure its logs are kept for CERT-In's rolling 180 days within India.

Step 5: pilot, then move in waves

Start with a pilot of low-risk VMs. Each target platform provides conversion tooling, and KVM-based platforms can also use the open-source virt-v2v. Take a fresh backup before each conversion, keep the source VM powered off but intact until the migrated one is verified, and agree a rollback window in advance. Move in waves of similar workloads, measure each wave, and only then schedule the next. After the last wave, run a full DR test on the new platform. Our guide to testing disaster recovery shows how.

If you only do three things this quarter

First, get your exact core count, the features you use and your renewal date onto one page. Second, sort your twenty most important workloads into keep, move, cloud and retire. Third, pilot one non-critical workload on an alternative platform before you negotiate the renewal. A working pilot is the strongest position you can negotiate from, whether you end up staying or going.

Where Zyvark fits

This is the work behind our DC Migration, Virtualization & Consolidation service: discovery and dependency mapping, a workload-by-workload plan, conversion, cut-over and hypercare, with backup and DR verified on the new platform before hand-over. It starts with a free discovery call and a fixed-scope, written proposal. If you would rather run it yourself, this guide is the order we would do it in.

Sources

heise online, “VMware: Companies will have to license 72 instead of 16 cores in future” (April 2025) — 72-core minimum from 10 April 2025 for new licences and renewals; abolition of perpetual licences in spring 2024. The Register, “VMware to lose 35 percent of workloads in three years” (11 September 2025) — Gartner's Julia Palmer on workloads moving by 2028, migration duration and selective re-platforming; hyperscaler resale change. This article is engineering guidance, not licensing or legal advice; confirm entitlements with Broadcom or an authorised partner.