VMware to Container Migration Strategy

Containerisation as an answer to VMware licensing pressure is intuitively appealing: containers consume host resources more efficiently than VMs, the underlying platform (Kubernetes plus a container runtime) does not carry VMware licensing, and the operational model maps well to modern application architectures. The intuition is correct in important respects. It is also incomplete. Successful VMware-to-container migrations are workload-selective, require real application refactoring effort, and depend on operational maturity that takes time to build. This article is a working framework for the migration decision and execution.

The fundamental shift

VMware virtualisation and container orchestration solve overlapping but distinct problems. Virtualisation abstracts hardware so that one physical server can run multiple isolated operating system instances; containers abstract the operating system so that one OS instance can run multiple isolated application processes. Both reduce per-workload hardware cost, but they do so at different layers.

The implication for migration: moving from VMware to containers is not a forklift exercise. It is an application architecture change. Workloads designed to run as single processes in single-purpose VMs do not naturally fit into the container model without refactoring. Workloads designed as multi-process VMs with internal orchestration are even further from container-native shape. Some workloads — third-party commercial software, legacy ERPs, certain database systems — are not container-suitable at all and need to remain on virtualised infrastructure.

The workload-suitability spectrum

Workloads sort into four bands for container migration suitability:

Band 1: Container-native. Modern microservice applications, stateless web tiers, API services, batch processing jobs. These workloads either already run in containers or can be containerised with minimal effort. The VMware estate hosting them can be reduced 60-90% by containerisation.

Band 2: Container-suitable with refactoring. Multi-tier applications, monoliths with reasonable architecture, applications using standard middleware (Java EE, .NET, Node, Python web frameworks). These workloads benefit from containerisation but require investment to decompose, instrument, and make stateless. Typical refactor effort: 1-6 months per application depending on complexity.

Band 3: Containerisable with significant constraints. Legacy applications with hardcoded paths, applications dependent on specific OS features, applications with significant local state, applications using non-portable third-party libraries. These can be containerised but require either lift-and-shift via specialised tools (which limits the operational benefit) or substantial refactoring.

Band 4: Not container-suitable. Commercial software not certified for containers, applications with hard hardware dependencies (GPU certification, specific drivers), legacy databases requiring full OS access, mainframe-style transactional systems. These workloads need to remain on virtualised infrastructure.

A realistic VMware-to-container migration plan starts by classifying the workload portfolio into these bands. The savings opportunity comes from Bands 1 and 2; Bands 3 and 4 stay on VMware (or migrate to alternative virtualisation platforms like Proxmox or Nutanix AHV).

The platform choice — Kubernetes, OpenShift, Tanzu, or managed

Once the container migration decision is made, the platform choice has material implications:

Vanilla Kubernetes (typically via a distribution like Rancher, EKS Anywhere, or Cluster API). Maximum flexibility, lowest licence cost, highest operational burden. Good fit for organisations with strong platform engineering capability.

Red Hat OpenShift. Commercial Kubernetes distribution with broader application platform capabilities and enterprise support. Significant licence cost but reduced operational burden. Common choice for enterprises with existing Red Hat relationships.

VMware Tanzu. The VMware-native Kubernetes story. Operationally well-integrated with vSphere, but licensing under Broadcom has become expensive and Tanzu's strategic future under Broadcom is unsettled. Use case has narrowed.

Public cloud managed Kubernetes (EKS, AKS, GKE). Operationally simplest. Cost depends on consumption. The natural choice for new container workloads being deployed in cloud-native architectures.

The Broadcom-pressure context typically pushes enterprises toward vanilla Kubernetes (for cost), OpenShift (for enterprise support), or public cloud managed (for operational simplicity), depending on the use case. Tanzu's role is diminishing for new deployments.

The state problem

The most common cause of container-migration failure is mishandled state. Containers are designed to be ephemeral; persistent state requires external systems. Workload migrations that don't address state cleanly produce containers that are hard to scale, hard to update, and hard to operate.

The pattern that works: identify the state in each workload, extract it to managed external systems (databases, object storage, message queues, dedicated stateful services), and design the container layer to be stateless. The pattern that fails: containerise the workload while leaving state internal to the container, treating containers like small VMs.

The state extraction is often the largest single piece of work in a container migration. For a typical multi-tier application, state extraction can take longer than the containerisation itself. Plan for it explicitly.

The operational maturity gap

Running containers well at scale requires capabilities that VMware-centric teams typically have not developed:

• Container image lifecycle management — building, scanning, storing, versioning, and rolling out images across environments
• Kubernetes-native observability — Prometheus, Grafana, distributed tracing, log aggregation tuned for ephemeral workloads
• GitOps and declarative deployment — managing cluster state as code rather than imperative deployment
• Network and security policy at the container level — service mesh, network policies, runtime security tooling
• Capacity planning for non-deterministic workloads — autoscaling, bin-packing, multi-tenant resource sharing

The skills gap is typically the binding constraint on migration pace. Enterprises that try to outrun their operational maturity find themselves with production container workloads they cannot effectively operate, which produces incidents that erode the case for further migration.

The pattern that works: start with a constrained set of workloads, build operational maturity through real production experience, expand scope as the team matures. The pattern that fails: declare a "Kubernetes-first" strategy across the enterprise without investing in the operational capability to back it up.

Cost modelling — what migration actually saves

The savings case for container migration is real but often overstated in initial estimates. A more realistic model:

Compute consolidation. Containers can run at 2-4x the density of VMs for suitable workloads. This translates to reduced host count and proportional reduction in VMware licensing.

Licence elimination. Migrated workloads no longer require VMware licensing for their portion of the estate. The savings depend on what edition of VMware the hosts were running under.

Platform cost. Container platform licensing (OpenShift, Tanzu) or operational cost (vanilla Kubernetes) offsets some of the VMware savings.

Operational cost. Container operations require investment that typically increases operational cost in the short term and reduces it once mature.

Application cost. Refactoring effort is a real one-time cost that needs to be amortised over the savings period.

Net savings for a typical mid-size migration: 20-40% reduction in VMware costs in the first two years; 40-70% reduction in three to five years once the platform matures. Aggressive early estimates often suggest 70%+ savings in year one, which rarely materialises.

Migration patterns

The greenfield strategy

New workloads built directly on the container platform; existing VMware workloads remain in place. Lowest risk, slowest migration. Suits organisations that need to demonstrate container capability before committing to broader migration.

The strategic-workload strategy

Identify 3-5 workloads where container migration produces material business benefit (faster deployment, better scalability, multi-cloud portability). Migrate these as proof points. Build the operational capability and the cost case from the strategic workloads.

The portfolio sweep

Classify the entire VMware portfolio against the suitability bands, prioritise by savings potential, and execute migration as a multi-year program. Highest savings potential, highest execution risk. Suits organisations with mature program management capability.

The cloud-native rebuild

Use the migration as an opportunity to rebuild applications cloud-native rather than just containerise them. Maximum long-term value, longest timeline, highest application engineering investment.

The compliance bridge

The VMware estate during migration is at elevated audit risk because:

• The deployment is in motion, making inventory harder to maintain
• Decommissioning lags often leave hosts licensed but underutilised, which Broadcom may interpret as a licensing optimisation opportunity
• Hybrid VMware/container deployments may be configured in ways that don't fit cleanly into the VMware entitlement model
• The migration itself is a visible signal to Broadcom that the customer may be reducing future spend, which can trigger audit prioritisation

The defensible position during migration requires explicit inventory management — what is currently in scope, what has been decommissioned, what is in transition. Decommissioned hosts should have their VMware software actually removed (not just powered off) and the documentation should reflect the decommissioning.

Common migration pitfalls

Underestimating the application refactor

Workloads classified as Band 2 (container-suitable with refactoring) routinely take longer to refactor than initial estimates suggest. Plan with 50-100% buffer on the engineering estimate.

Treating containers as small VMs

Containers that maintain VM-style state, configuration, and operational model lose most of the operational benefit. The migration has to embrace the container model, not paper over it.

Choosing the wrong platform for the team

Vanilla Kubernetes is operationally demanding; teams without strong platform engineering capability struggle. OpenShift is expensive but reduces operational burden. The choice should reflect the team's capability profile, not just the licence-cost comparison.

Ignoring the state systems

Container migrations that don't plan for external state — databases, object storage, message queues — produce brittle container deployments. The state systems are typically larger investments than the container platform itself.

Letting compliance drift during migration

The migration period is the highest-risk audit window. Compliance discipline must be tighter during migration, not looser.

When containers are not the answer

Several workload categories where container migration is the wrong move:

• Third-party commercial software not certified for containers — vendor support may not extend to containerised deployments
• Workloads requiring specific OS features — kernel modules, low-level hardware access, certain security features
• Legacy databases at scale — large transactional databases typically remain on dedicated infrastructure
• Workloads with strict regulatory isolation requirements — some financial and healthcare workloads require VM-level isolation
• Applications nearing end-of-life — refactoring effort doesn't pay back over the remaining application lifetime

For these workloads, alternatives to containers — Proxmox, Nutanix AHV, public cloud IaaS — may be better answers to the VMware-cost question. The migration strategy needs to be portfolio-aware, not single-platform-aware.

Frequently asked questions

How much of our VMware estate can realistically migrate to containers?

Varies by portfolio. Modern application-heavy estates can typically migrate 40-70% of workloads. Legacy-heavy enterprise estates often migrate 20-40%. The portfolio classification work tells the answer.

How long does a typical migration take?

3-5 years for a substantial portfolio migration including operational maturity build. Shorter for greenfield-only strategies; longer for cloud-native rebuilds.

What's the typical first-year saving?

10-25% reduction in VMware costs in year one is realistic. Larger savings require the platform to mature and the migrated scope to be substantial.

Should we use Tanzu given we're already a VMware customer?

Tanzu's positioning under Broadcom is uncertain. New container deployments typically choose vanilla Kubernetes, OpenShift, or managed cloud Kubernetes rather than Tanzu. Existing Tanzu deployments are increasingly being migrated to alternatives.

Does container migration eliminate Broadcom audit risk?

For migrated workloads, yes — they no longer use VMware. For remaining workloads, audit risk continues and is typically elevated during the migration period because of inventory volatility.

What container platform is best for VMware customers migrating?

No single answer. Strong platform-engineering teams typically choose vanilla Kubernetes. Enterprises wanting commercial support choose OpenShift. New cloud-native workloads typically go to managed cloud Kubernetes. The choice should reflect team capability and workload destination.