Companies stopping VMware… without having chosen what comes next

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 is neither a migration. Nor is it a chosen status quo. It's something more uncomfortable — a freeze on investment, a scope reduction, a halt to long renewals, a team evaluating alternatives without a clear mandate to put them into production. An in-between state that, based on what we observe in the field over the past 18 months, likely affects as many organizations as those that have actually started migrating.

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 isn't inertia. It's a rational decision in a context of uncertainty. Organizations don't want to further commit to a vendor whose commercial trajectory has become unpredictable. But they're not ready to migrate either.

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

There are environments where staying on VMware, even temporarily, is objectively the most responsible decision. This isn't capitulation — it's a realistic reading of constraints.

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.

Pretending all these situations can be resolved in 6 months with goodwill and a successful POC would be false. What we encounter in these environments is often an 18-36 month migration plan, with explicitly planned coexistence phases and precise criteria for when the cutover is safe.

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, for 15 years, offered an answer to that question: yes, if you buy the right licenses and the right support, you have operable infrastructure even with modestly sized teams. This value proposition is real. It has structured 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.

It's not about having made the right technology choice. It's about having put in place the conditions for any technology decision to be 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.

The reality of what many organizations are living today isn't a drama. It's not an inexcusable delay either. It's a difficult organizational transformation, slowed by real constraints, in a market context that hasn't yet found its equilibrium. Recognizing this honestly is the starting point for moving in the right direction.