Broadcom after VMware: the problem isn't just the price
The reflex is understandable: you open the invoice, compare, and draw conclusions. In practice, cost is the visible part. The structural issue is dependency.
Since the Broadcom changes, the conversations I see in IT leadership have shifted in nature. It's no longer just about TCO. It's about technical and contractual room to maneuver over the next three years.
What becomes difficult
- Forecasting a stable infrastructure budget.
- Defending a technical roadmap without a credible exit option.
- Arbitrating between short-term continuity and mid-term autonomy.
The key point: a critical foundation should not depend on a single commercial assumption.
Where plans typically go wrong
The first business cases usually miss the real transition costs:
- temporary platform coexistence,
- on-call load during migration waves,
- additional DRP tests,
- upgrading runbook and change management practices.
The result: migration underestimated, schedule compressed, then operational friction.
An honest opinion
Moving too fast is sometimes just as risky as doing nothing.
It's not a popular thing to say, but on certain environments you first need to rebuild operational discipline before accelerating the migration. Otherwise you're just replacing a vendor dependency with an operational fragility.
What works better in the field
- Separating the contractual stream from the technical stream.
- Segmenting workloads by criticality and reversibility.
- Requiring rollback proof before opening sensitive migration waves.
- Keeping a transitional VMware layer where the business risk demands it.
This isn't a concession. It's risk management.
Position
VMware still has real strengths, especially in environments that have been tooled around it for years. Proxmox brings genuine gains in autonomy and cost. Both statements can be true at the same time.
The mature decision isn't ideological. It's a trajectory decision: how to regain independence without breaking service continuity.