There is a situation that articles about VMware migration rarely describe, because it's harder to illustrate than a clean before/after: organizations that have decided to stop moving forward with VMware, without having yet decided where to go.
This intermediate posture combines an investment freeze, scope reduction, a halt to long renewals and a team evaluating alternatives without a clear mandate to put them into production. We encounter it regularly in audits conducted since Broadcom acquired VMware.
This reality deserves to be described honestly.
The stop without a designated successor
The most common dynamic we see isn't "we're moving from VMware to Proxmox." It's "we're not renewing beyond what we have, and we'll see."
Concretely, this looks like:
- stopping new VMware license acquisitions, without deploying a replacement solution;
- freezing projects to extend virtual infrastructure on VMware;
- not renewing support contracts beyond the minimum needed to cover current production;
- refusing to commit to VCF (VMware Cloud Foundation) without a full evaluation of alternatives;
- infrastructure projects put on hold waiting for an architecture decision that doesn't come.
This pause can be a rational response to uncertainty: avoid deepening the commitment to a vendor whose commercial trajectory has changed, without launching a migration the organization is not ready to absorb.
What's really blocking action
What prevents these organizations from acting isn't always technical. And this is where part of the usual analysis misses the target.
On the surface, you see evaluations of Proxmox, Nutanix, OpenStack, sometimes cloud solutions. POCs started. Benchmarks run. Reports produced. But decisions don't come.
The deeper reason is often organizational. A hypervisor migration in a production environment cannot be driven solely by the infrastructure team. It requires an IT Director or executive sponsor with a clear mandate, a validated multi-year budget, coordination with application teams, business agreement on acceptable maintenance windows, and project risk governance.
Getting this alignment in a large organization takes time. And in the post-Broadcom context, many decisions at this level have been frozen by a simple question: "Do we migrate to Proxmox, or do we prefer to wait and see if Broadcom corrects its commercial policy?"
That question doesn't yet have a definitive answer in many organizations. And while it stays open, the project advances little.
What the inventory reveals when you start looking
For many organizations, the Broadcom pressure was the first occasion to seriously take inventory of their VMware environment. And what that inventory reveals often slows the decision further.
What we regularly discover:
Undocumented dependencies. VMs calling each other without anyone having mapped the flows. Applications depending on internal DNS resolution tied to vCenter configuration. Backups configured on datastores that no longer appear in the official documentation.
Workloads without an owner. VMs in production for four years, created by someone who's no longer with the company. Nobody knows if they still do anything useful. Nobody dares to shut them down. They won't be migrated until they're identified.
DRP plans that haven't been tested. Documented recovery plans assume infrastructure capabilities that haven't been verified since the last major change. A forced migration would reveal these gaps at the worst moment.
ITSM processes tied to vCenter. Scripts, CMDB automations, monitoring flows that directly use the VMware API. Replacing the hypervisor requires rebuilding these integrations — work that has often not been estimated.
What the inventory makes visible is actually the governance debt accumulated during the years when VMware worked silently. The technology was masking process problems. Broadcom's pressure removes that mask.
The strategic pause: neither migration nor commitment
The state many organizations find themselves in today can be described this way: they know the old trajectory is over, but they're not ready to commit to the new one.
This is a legitimate posture. It has its own logic:
Continue operating the existing infrastructure. Avoid investing in something that may be replaced in 18 months. Reduce the risk of production disruption by not forcing a transformation the organization isn't ready to absorb. Buy time to take inventory, train teams, and wait for the alternatives market to stabilize.
What this posture costs is predictability. From an external governance perspective (audits, risk management, executive committees), an infrastructure with a fuzzy trajectory is harder to justify than one with a clear plan — even if that plan is "we stay on VMware for another 3 years while we prepare the migration."
Why some migrations are intentionally slowing down
Among organizations that have officially launched a migration, some are deliberately slowing down. Not for lack of will, but because production reality imposes its own constraints.
A hypervisor migration in a critical production environment, with application workloads that haven't been tested on the target platform, with teams upskilling in parallel with current operations, with maintenance windows limited by business constraints — this migration cannot go fast without exposing production to disproportionate risk.
Organizations that are intentionally slowing down are making the following calculation: better to have two years of cautious migration than six months of aggressive migration followed by a major outage. This calculation is defensible. The pressure for speed rarely comes from the infrastructure team itself — it comes from finance departments wanting to exit VMware costs, or IT teams that communicated overly optimistic timelines.
Where VMware remains temporarily the least risky choice
In some environments, remaining temporarily on VMware is the lowest-risk decision when application, staffing and contractual constraints are considered together.
These environments share common traits:
- Critical applications whose vendors don't yet certify their product on Proxmox or alternatives;
- Windows workloads heavily integrated with specific VMware features (vSAN, NSX, DRS) whose porting requires application redesign;
- Teams without deep Linux experience, for whom operating Proxmox in production without structured vendor support represents a real operational risk;
- Multisite DR architectures that rely on VMware-native replication mechanisms not available elsewhere without a change of approach.
A successful POC does not determine the schedule. In these environments, duration depends on application dependencies, change windows and required coexistence phases; cutover criteria must be established before the timeline.
The core problem: operational maturity
The central question that Broadcom made visible isn't "which hypervisor to choose." It's "is our organization ready to operate critical infrastructure without relying on a vendor that absorbs complexity on our behalf?"
VMware has long offered a tightly integrated platform that modestly sized teams could operate with the appropriate licenses and support. That value proposition has shaped many organizations.
Proxmox, OpenStack, or other open-source alternatives distribute complexity differently. They're more flexible, less expensive in licenses, but they require more internal competence. They don't come with a Broadcom account manager who can escalate a P1 incident at 3 AM.
For some organizations, that's acceptable. For others, it's not yet the case — not because they lack budget, but because they don't yet have the technical profiles and operational processes to own that responsibility.
What will allow organizations to exit this intermediate state
The organizations that will successfully exit this strategic pause are those that will have addressed the problem at the right layer.
The priority is to establish the conditions that make the technology decision executable:
- A complete, maintained inventory of the existing environment;
- Identified application owners for every workload;
- DRP plans tested and validated on the target platform before cutover;
- A team with the skills or external support needed to operate what it deploys;
- A sponsor with a mandate and a multi-year budget;
- A valid rollback plan through the final phase.
These conditions aren't spectacular. They don't make good headlines. But they're what makes the difference between a migration that goes well and one that generates incidents for six months.
Many organizations are navigating a difficult organizational transformation, slowed by real constraints and an unsettled market. Making those constraints explicit turns passive waiting into a managed trajectory.