VMware audit and Broadcom exit strategy
Mission context
This industrial group operates across multiple geographic sites with a centralised VMware infrastructure. When the Broadcom renewal came with a significant price increase, the IT department found itself in an uncomfortable position: neither the actual application dependencies, nor the precise cost of staying, nor the risks of leaving were objectively documented.
The objective was not to "migrate to Proxmox". It was to have a solid technical position before any strategic decision.
:::Mission context Broadcom renewal in 8 months. No visibility into application dependencies, actual financial exposure, or the feasibility of a migration without production disruption. :::
What the audit revealed
Of 180 VMs inventoried, the real functional scope was significantly more complex than the declared mapping. Several services classified as "non-critical" in the documentation were part of industrial processing chains. Middleware dependencies existed in local operational scripts, invisible in vCenter.
:::Field observation The vCenter inventory was clean. The mapping of actual dependencies lived in the heads of the operations team — not in the documentation. :::
The existing DRP assumed a recovery sequence that no longer matched the current application behaviour. It had been documented two years earlier and had never been rehearsed.
Broadcom exposure analysis
Three scenarios were modelled over 3 years:
- Full VMware renewal — projected Broadcom cost under the new licensing conditions
- Progressive migration to Proxmox — migration cost + target infrastructure, by waves
- Temporary hybrid coexistence — partial VMware retention for dependent workloads, priority migration of the rest
The financial comparison showed a substantial gap from year 2 onwards, even after including the full cost of migration.
:::Decision retained The IT department chose scenario 3: progressive migration by business dependency, temporary VMware retention on an identified subset, full exit within 18 months. :::
Wave migration plan
The audit produced a migration matrix organised not by cluster convenience but by business dependencies. Each wave includes:
- workloads that can be moved without impacting subsequent ones,
- a technical go/no-go criterion before starting,
- a defined and documented rollback point,
- an explicit rollback decision deadline (not left to in-the-moment judgement).
The most dependent and most critical workloads were placed in the final waves, after operational confidence had been established in the earlier ones.
What changed the decision
The tipping point was not the performance benchmark. It was the incident simulation conducted in a workshop with ops and application teams together.
When asked "who approves an application failover during a migration incident?" — silence. When asked "what is the decision deadline for a rollback?" — three different answers.
:::What changed the decision The IT department stopped debating migration speed. It asked for: smaller waves, longer coexistence, and an actionable rollback matrix. :::
Result
Audit report delivered to IT management and the Executive Committee. Strategic decision made on objective technical and financial grounds, disconnected from Broadcom's commercial arguments. Wave migration plan approved with go/no-go criteria defined ahead of each stage.