Why Migrating from VMware Isn’t as Simple as Changing Hypervisors

The market is chaotic. Broadcom has fundamentally changed the rules of engagement for VMware customers, forcing enterprises to seek alternatives urgently. Vendors and analysts are pushing seemingly brilliant solutions: OpenShift Virtualization Engine (OVE), Kubernetes-based virtualization platforms, and alternative hypervisors.

The pitch is alluring: Escape vendor lock-in, save on licensing, future-proof your infrastructure. Just migrate your VMs from vSphere to [insert alternative here].

You’re being sold a tactical solution (hypervisor replacement) for what is actually a strategic decision (operating model transformation).

We’ve made this decision before—with Oracle. We know how to think strategically about platforms deeply embedded in business operations. We need to recognize that VMware decisions deserve the same strategic discipline.

Let Me Be Clear: This Isn’t Anti-Kubernetes or Anti-Red Hat

Kubernetes is outstanding for what it was designed to do: orchestrate containerized, cloud-native applications. I practice what I preach. My Virtual CTO Advisor and Stack Builder are both built on GCP Cloud Run—which runs on Kubernetes. I chose Kubernetes because they’re cloud-native, stateless services built for containers.

Red Hat OpenShift is one of the most mature cloud-native platforms available. When used correctly—as a Fourth Cloud platform for modernizing application delivery—it’s an excellent solution.

This piece isn’t about the technology. It’s about alignment. Vendors positioning OVE or alternatives as simple vSphere replacements are misrepresenting the decision enterprises face. You’re not choosing a hypervisor. You’re choosing an operating model.

The Oracle Lesson: We’ve Made These Decisions Before

When Oracle’s pricing became aggressive 20 years ago, we didn’t see mass database migrations. Why?

Because everyone understood Oracle databases were tied to business processes. The connection to business outcomes was obvious. ITDMs could articulate business risk to executives. Nobody thought “just swap databases” was viable.

Some customers successfully migrated from Oracle. These organizations had avoided deep Oracle integrations—minimal stored procedures, PL/SQL, or Oracle-specific features. They treated Oracle as a relatively “dumb” data store with business logic in the application layer.

Most customers stayed on Oracle. These organizations had deeply integrated with Oracle’s platform capabilities. They’d built business processes directly on Oracle-specific features and embedded operational complexity in the platform layer.

The difference wasn’t technology sophistication—it was the depth of platform integration.

Enterprises that stayed made good strategic decisions. Migration costs exceeded benefits because their operations were fundamentally built on Oracle’s platform. They accepted the vendor tax as the cost of operational continuity.

The argument is that Oracle is more important and highlights the application’s importance vs. undifferentiated infrastructure. If you lived through a failed cloud migration between 2015 and 2020, you already know the pain of repatriation and getting it wrong.

VMware decisions follow the same pattern.

The Two Types of VMware Customers

Type 1: Platform-Abstracted (The Minority)

These customers treat the hypervisor as relatively interchangeable:

• DR processes don’t depend on VMware-specific orchestration (no Site Recovery Manager)
• Automation is infrastructure-agnostic (Terraform, Ansible—not vCenter APIs)
• Networking isn’t built on NSX
• Storage management happens outside vSAN
• Team expertise is infrastructure-as-code, not VMware-specific

For Type 1 customers: Red Hat’s OVE argument makes sense. You can genuinely treat hypervisors as interchangeable. Nutanix AHV, Scale Computing, or OVE might work as straightforward replacements.

Type 2: Platform-Integrated (The Majority)

These customers have deeply integrated operations with VMware’s Software Defined Data Center:

• vSphere DRS for automated resource management
• NSX for network virtualization and micro-segmentation
• vSAN for storage policy-based management
• vCenter orchestration and automation workflows
• Site Recovery Manager for DR orchestration
• vRealize integrations for operations management

For Type 2 customers: You’re not just using a hypervisor—you’ve built your IT operating model on VMware’s SDDC platform. Changing this isn’t a hypervisor swap. It’s an operating model transformation.

Why VMware Is Your Operating Model, Not Just Infrastructure

VMware gave customers an “easy button” to the Software Defined Data Center—and most took it. This was VMware’s great success, but it means most VMware customers are Type 2. They built operational patterns, automation, and team expertise around VMware’s integrated platform—exactly what happened with Oracle.

VMware isn’t just “infrastructure”—it’s your IT operating model. It defines how you deploy applications, handle disaster recovery, maintain compliance, operate IT teams daily, and what capabilities you promise the business.

Moving that operating model has cascading business impacts: DR capabilities and RTO commitments, compliance frameworks, operational risk and team capability, service delivery timelines.

For Type 2 customers, this isn’t a commercial decision about hypervisor licensing. It’s a strategic decision about operating model transformation.

If you’re shaking your head “no” at this—you’re Type 1. And that raises a different question: If you’ve abstracted away from platform complexity and don’t need SDDC capabilities, why are you running on-prem at all? Type 1 customers might be better served by public cloud where abstraction is native.

The VCF 9 Reality: Licensing Change, Not Operational Change

Red Hat’s Stu Miniman notes that Broadcom is forcing customers to VCF 9, suggesting this creates a decision point between VCF 9 and OpenShift.

Let me clarify what VCF 9 migration actually means: It’s a forced licensing change, not a forced operational change.

vSphere remains a component of VCF 9. Type 2 customers can continue running vSphere with their existing operational model—they just pay for the full VCF 9 stack (NSX, vSAN, Tanzu, Aria Suite) whether they use it or not.

This is expensive shelfware—and it’s familiar territory. Many vSphere deployments historically paid for Enterprise Plus features they never used. VCF 9 just expands the unused components you’re paying for.

This is exactly the Oracle pattern. Oracle customers pay for Enterprise Edition features they don’t use. They accept the vendor tax as the cost of operational continuity because migration would cost more.

The VCF 9 forcing function doesn’t eliminate the Oracle decision—it makes the vendor tax more expensive, but the strategic framework remains unchanged.

The Economic Reality: It’s More Complex Than “License Savings”

Current market reality:

1. Broadcom won’t negotiate based on declining footprint. You pay for your current environment regardless of migration plans.
2. All Fourth Cloud paths require 3-5+ year timelines. Whether OpenShift, VCF 9, or alternatives—expect multi-year transformation.
3. You’ll run dual platforms during transition. This means paying both Broadcom AND the new platform vendor for 3-5 years.

Does transformation always cost more? No—the TCO is use-case specific:

• If you’re reducing expensive public cloud spend, dual platform cost might be offset by AWS/Azure savings
• If you’re gaining strategic capabilities (cloud-native development, AI/ML), the “cost” includes value of new capabilities
• If you’re purely escaping Broadcom with no strategic drivers, transformation likely costs more than staying

There’s no simple answer. You need outcome-based evaluation, not vendor-provided “savings” calculations.

The Three Viable Paths

Path 1: Stay on vSphere (The Oracle Model)

Best for: Type 2 customers with monolithic apps, finite lifecycles, no strategic Fourth Cloud need

Decision: Accept VCF 9 shelfware as the cost of operational continuity. This is the Oracle decision most enterprises made—and it was often right.

Path 2: Fourth Cloud Platform (VCF 9 or OpenShift)

Best for: Organizations with strategic need for cloud-native capabilities beyond cost savings

Reality: 3-5 year transformation, dual platform costs, organizational change required. Justified by platform capabilities, not Broadcom escape.

If you’re using Red Hat, go all-in on OpenShift as Fourth Cloud. Don’t just migrate VMs to OVE.

Path 3: Parallel Platforms (Most Common)

Best for: Mixed environments—traditional apps on VMs, cloud-native on containers

Reality: Traditional apps stay on vSphere. Cloud-native workloads go to OpenShift/K8s separately. No virtualization migration required.

Decision: Accept Broadcom costs for traditional VMs. Invest Fourth Cloud budget where it creates value—modern apps, AI/ML, microservices.

The WRONG Path: vSphere → OVE Without Strategic Context

Works for: Type 1 customers (platform-abstracted, minimal VMware integration)

Fails for: Type 2 customers (platform-integrated, SDDC operational model)

Why it fails: You’ve migrated platforms without gaining Fourth Cloud capabilities. You have expensive, complex infrastructure (now K8s instead of vSphere) without strategic benefit.

What Actually Works

1. Understand which type of customer you are Be honest about platform integration depth and operational dependency on VMware SDDC features.

2. Define outcomes you actually need Not “escape Broadcom”—what business capabilities matter? What’s driving this beyond licensing?

3. Evaluate total cost to achieve those outcomes Include dual platform costs, organizational transformation, public cloud changes, business risk.

4. Make decisions based on strategic fit

• Type 1: Hypervisor alternatives might work
• Type 2: Evaluate VCF 9 vs. OpenShift as Fourth Cloud or stay on vSphere
• Mixed: Parallel platforms are fine—right tool for right workload

We’ve Made These Decisions Well Before

We already know how to make platform decisions strategically. We did it with Oracle.

We understood Oracle was tied to business processes. We articulated migration risk. We made outcome-based decisions about whether to stay or migrate.

VMware is your IT operating model. It deserves the same strategic evaluation we applied to Oracle.

When you made Oracle decisions, you asked:

• What business processes depend on this platform?
• What’s the disruption risk?
• What capabilities would we gain or lose?
• What’s the total cost including business disruption?

Ask the same questions about VMware:

• What operational capabilities depend on your SDDC platform?
• What’s the risk to DR, compliance, operational continuity?
• What’s the total cost including organizational transformation?
• What’s the strategic value beyond escaping Broadcom?

Treat this decision like Oracle. Understand what you’re trying to achieve. Evaluate total cost and risk. Make choices based on business outcomes and operational reality—not vendor marketing or licensing panic.

The vendors are selling tactical thinking. Migrating from vSphere isn’t as simple as changing hypervisors—especially if you took VMware’s SDDC easy button.

The decision isn’t commercial (licensing costs). It’s strategic (your operating model and the capabilities your infrastructure delivers).

We made good Oracle decisions because we understood they were strategic. Apply the same discipline to VMware.

That’s how good decisions get made. We know how to do this. We’ve done it before.

What type of VMware customer are you? How deeply integrated is your operational model with VMware’s SDDC capabilities? I’d value hearing what you’re seeing as you evaluate your options.