VMware to Kubernetes Migration: A Practical Roadmap for Enterprises

The Licensing Wake-Up Call

Since Broadcom’s acquisition of VMware, the licensing landscape has shifted dramatically. Perpetual licenses are gone. Per-socket pricing has been replaced with per-core bundles. For many enterprises, renewal quotes have arrived at two to five times the previous cost. Whether or not you were planning a modernization effort, the economics now demand that you evaluate alternatives.

This is not a post about panic. It is a structured roadmap for organizations that need to move deliberately — understanding which workloads to migrate, where to migrate them, and how to do it without disrupting operations.

Step 1: Assessment — Know What You Have

Before making any architectural decisions, you need a complete inventory. Most organizations are surprised by what they find running on their vSphere clusters.

We recommend building a workload inventory spreadsheet with the following columns:

VM Name	vCPU	RAM (GB)	Storage (GB)	OS	Application	Owner	Stateful?	Network Dependencies	Last Modified
db-prod-01	8	32	500	RHEL 8	PostgreSQL	Platform	Yes	VLAN 100, needs low latency to app tier	2026-01
web-fe-03	2	4	20	Ubuntu 22.04	Nginx + React	Frontend	No	Public-facing, WAF in front	2026-02

Automate this with VMware’s own tooling:

# Export VM inventory using govc
govc ls /datacenter/vm/**/* | while read vm; do
  govc vm.info -json "$vm" | jq '{
    name: .virtualMachines[0].name,
    cpu: .virtualMachines[0].config.hardware.numCPU,
    memory_mb: .virtualMachines[0].config.hardware.memoryMB,
    guest_os: .virtualMachines[0].config.guestFullName,
    power_state: .virtualMachines[0].runtime.powerState
  }'
done > vm-inventory.json

Beyond the raw inventory, capture dependencies. Which VMs talk to each other? Which ones depend on shared storage? Tools like VMware vRealize Network Insight or open-source alternatives like Netbox can help map these relationships. The dependency map will drive your migration sequencing later.

Step 2: Workload Categorization

Not every workload should go to Kubernetes. Not every workload should stay as a VM. We use a four-category framework:

Category A: Containerize and Move to Kubernetes

These are stateless or near-stateless applications with modern architectures. Think web frontends, REST APIs, microservices, batch jobs, and CI/CD runners. They benefit most from Kubernetes features like horizontal autoscaling, rolling updates, and declarative configuration.

Category B: Lift-and-Shift to Alternative Hypervisor

Some workloads are fundamentally VM-shaped and will remain so. Legacy applications with kernel dependencies, Windows Server workloads, appliance VMs from vendors, and anything with a hardware license dongle. These should move to a cost-effective hypervisor — more on Proxmox below.

Category C: Refactor Over Time

These are workloads that could eventually be containerized but need investment. Monolithic Java applications, stateful middleware, and databases that would benefit from managed services. Plan for these in a later phase.

Category D: Decommission

Every migration assessment reveals VMs that nobody owns, nobody uses, and nobody will miss. Be aggressive about identifying these. In our experience, 10 to 20 percent of VMs in a typical enterprise fall into this category.

Step 3: Proxmox as a VMware Alternative

For Category B workloads, Proxmox VE is the most compelling VMware alternative for enterprises. It is open-source, based on KVM and LXC, and provides a mature web UI with clustering, high availability, and live migration — the features that made vSphere indispensable.

Key advantages over VMware:

• No per-socket or per-core licensing. Proxmox is free to use. Enterprise support subscriptions exist but are a fraction of VMware costs.
• ZFS and Ceph integration for software-defined storage without additional licensing.
• Familiar concepts. Clusters, resource pools, HA groups, and live migration all work similarly to vSphere.
• API-driven. Full REST API for automation, plus Terraform has a well-maintained Proxmox provider.

A basic Terraform configuration for provisioning a VM on Proxmox:

resource "proxmox_vm_qemu" "database" {
  name        = "db-prod-01"
  target_node = "pve-node-01"
  clone       = "rhel8-template"

  cores   = 8
  memory  = 32768
  scsihw  = "virtio-scsi-single"

  disks {
    scsi {
      scsi0 {
        disk {
          size    = "500G"
          storage = "local-zfs"
        }
      }
    }
  }

  network {
    bridge = "vmbr0"
    model  = "virtio"
    tag    = 100
  }

  lifecycle {
    ignore_changes = [network]
  }
}

This slots directly into the GitOps pipeline we described previously — Terraform state in Git, changes via merge requests, CI/CD applying the plans.

Step 4: Kubernetes for Containerized Workloads

For Category A and eventually Category C workloads, Kubernetes is the target. The question is which Kubernetes. Options include:

• Managed Kubernetes (EKS, AKS, GKE) if you are moving to public cloud.
• On-premises Kubernetes (RKE2, k3s, Talos Linux) if you are staying in your own data center.
• Hybrid — a common pattern where stateless workloads run in the cloud and stateful workloads remain on-premises.

For on-premises deployments, we have had excellent results with RKE2 running on Proxmox VMs. This gives you a familiar VM management layer underneath Kubernetes, which operations teams appreciate during the transition period.

The containerization process for each application typically follows this pattern:

1. Build a container image. Start with the application’s existing deployment process and translate it to a Dockerfile.
2. Write Kubernetes manifests. Deployments, Services, ConfigMaps, and if stateful, PersistentVolumeClaims.
3. Run in parallel. Deploy the containerized version alongside the VM version. Route a percentage of traffic to validate.
4. Cut over. Once validated, decommission the VM.

graph LR
    subgraph Phase 1 - Months 1-3
        A1[Assess Workloads]
        A2[Build Proxmox Cluster]
    end
    subgraph Phase 2 - Months 3-6
        B1[Migrate VM Workloads]
        B2[Deploy Kubernetes]
    end
    subgraph Phase 3 - Months 6-12
        C1[Containerize Apps]
        C2[Decommission VMware]
    end
    A1 --> B1
    A2 --> B1
    B1 --> C1
    B2 --> C1
    C1 --> C2

Step 5: Phased Migration Plan

We structure every migration into four phases spanning 6 to 18 months depending on the environment size:

Phase 1 (Month 1-2): Foundation

• Complete workload assessment and categorization.
• Deploy Proxmox cluster alongside existing vSphere.
• Deploy Kubernetes cluster (start with non-production).
• Set up observability stack from day one.
• Establish the GitOps pipeline for both Proxmox and Kubernetes.

Phase 2 (Month 3-6): Quick Wins

• Migrate Category D (decommission unused VMs).
• Migrate Category B low-risk workloads to Proxmox (development, staging environments).
• Containerize and deploy Category A workloads to Kubernetes (start with non-production).
• Validate networking, storage, and backup procedures on the new platforms.

Phase 3 (Month 6-12): Production Migration

• Migrate Category B production workloads to Proxmox.
• Move Category A production workloads to Kubernetes.
• Begin Category C refactoring for high-value workloads.
• Reduce vSphere cluster size as VMs are migrated.

Phase 4 (Month 12-18): Optimization

• Complete remaining Category C refactoring.
• Decommission vSphere infrastructure.
• Optimize Kubernetes resource requests and limits based on production metrics.
• Implement advanced patterns: autoscaling, service mesh, progressive delivery.

Migration Tooling

For the actual VM migration process, several tools help:

VM to VM (vSphere to Proxmox):

# Export OVA from vSphere
govc export.ovf -vm /datacenter/vm/db-prod-01 ./export/

# Convert to qcow2 for Proxmox
qemu-img convert -f vmdk -O qcow2 \
  export/db-prod-01-disk1.vmdk \
  db-prod-01-disk1.qcow2

# Import into Proxmox
qm importdisk 101 db-prod-01-disk1.qcow2 local-zfs

VM to Container:

There is no magic tool for this. It requires understanding the application. But for straightforward web applications, the pattern is often:

FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf

Risk Management

Every migration carries risk. Here is how we mitigate the common ones:

Data loss. Always migrate storage with verified checksums. Test backup and restore on the target platform before cutting over production.

Network disruption. Plan IP address management carefully. If workloads keep their IPs during migration, use bridged networking on Proxmox. If IPs change, update DNS and allow TTLs to expire before decommissioning the source.

Performance regression. Benchmark before and after. KVM (which Proxmox uses) has near-native performance for most workloads, but I/O-intensive applications should be tested thoroughly.

Team readiness. This is often the biggest risk. Train your operations team on Proxmox and Kubernetes before starting production migrations. We have seen organizations skip this step and regret it.

The Business Case

For a typical mid-sized enterprise running 200 VMs across 10 ESXi hosts, the rough economics look like this:

• VMware renewal (post-Broadcom): 150,000 to 300,000 EUR per year depending on the bundle.
• Proxmox enterprise subscription: approximately 5,000 EUR per year for the same node count.
• Migration cost (professional services + internal effort): 100,000 to 200,000 EUR one-time.
• Break-even: typically within the first year.

The numbers vary, but the direction is consistent. And unlike a VMware renewal, the migration investment also modernizes your platform, improves automation capabilities, and positions you for cloud-native patterns.

What Comes Next

Migration is not the end — it is the beginning of operating a modern platform. Once your workloads are on Kubernetes, you need proper observability, secrets management, and GitOps workflows to operate them effectively.

The organizations that treat this licensing disruption as an opportunity to modernize — rather than just a cost problem to solve — come out significantly stronger. The key is to plan deliberately, migrate in phases, and invest in the operational foundations from the start.