On this page
The largest enterprise platform shift since cloud adoption is happening now.
Broadcom’s acquisition of VMware accelerated a migration that was already underway. The combination of licensing pressure, the strategic case for cloud-native platforms, and the operational requirements of AI workloads has crossed a threshold for most large enterprises. Migration is no longer a question of if; it is a question of how, and how fast.
What most organisations are about to discover is that the migration is not the hard part. The hard part is what they have on the other side of it.
What Most Migrations Get Wrong
The pattern is consistent across organisations starting a VMware-to-Kubernetes migration. It usually involves three connected mistakes.
Treating it as an infrastructure project
The migration sits with the infrastructure team. The plan is to replace one platform with another, on a timeline driven by the licensing cycle. The metrics are workloads migrated, clusters built, and dollars saved on the VMware bill.
This framing produces an outcome where the migration completes, the licensing pressure goes away, and the engineering organisation ends up with a Kubernetes estate that operates in roughly the same way the VMware estate did. The cost line moves; the operating model does not.
The migrations that produce strategic value are framed as platform engineering programmes, not as infrastructure replacements. The Kubernetes estate on the other side is supposed to enable things the VMware estate could not - self-service, standardised patterns, support for modern workload types, faster delivery cycles. None of those follow automatically from changing the hypervisor.
Underestimating the platform investment
A working Kubernetes platform is not just a Kubernetes cluster. It is a set of capabilities - golden paths, self-service workflows, consistent observability, security and policy enforcement, cost attribution, ownership models - that let application teams ship to it without thinking about the infrastructure underneath.
Most VMware-to-Kubernetes migration plans budget the cluster and underestimate everything else. They assume the platform capabilities will emerge during the migration, organically, as teams encounter problems and solve them.
This is the same trap that early Kubernetes adopters fell into a decade ago. It produces an estate where every team has solved similar problems slightly differently, where there are no standard patterns, and where the platform team is permanently in the critical path for routine operations.
The platform investment has to come before the migration, not during it. Otherwise the migration produces a Kubernetes equivalent of the VMware estate it was supposed to replace - the same patterns, the same exceptions, the same operational burden, in a different runtime.
Lift and shift as the default target
There is genuine value in VM-on-Kubernetes runtimes for specific workloads that cannot be containerised in a reasonable time frame. For those workloads, KubeVirt and similar tools provide a credible path.
For most workloads, lift and shift is the wrong target. A VM that runs unchanged on Kubernetes carries forward every assumption it had on VMware: that infrastructure is provisioned by ticket, that scaling is a manual decision, that observability is bolted on, that the lifecycle is multi-year. The Kubernetes runtime underneath does not change any of those properties.
The value of the migration comes from converting workloads to platform patterns. A workload that was a long-lived VM becomes a deployment with autoscaling, health checks, and self-service updates. A workload that was a database VM becomes either a managed service or a clearly-defined stateful pattern on the platform. A workload that was a bespoke configuration becomes a standard one.
This conversion is the work. It is also the part most migration plans skip, because it is harder to estimate and harder to schedule than a straight runtime change.
The Pattern That Works
Migrations that produce strategic value usually follow a recognisable shape.
Build the platform first
Before the migration begins in earnest, the Kubernetes platform exists with the capabilities the workloads will need. Not all of them, but enough to support a meaningful fraction of the estate. Self-service deployment for the standard workload types. Consistent observability. A defined ownership model. A path to production that is genuinely easier than the VMware path.
The first workloads migrated are pilot workloads chosen to validate the platform. They are not the easiest workloads available; they are workloads that exercise the platform in ways that surface real problems. The pilot phase usually produces three to six months of platform refinement before the broader migration accelerates.
Define patterns, not migrations
The platform team identifies the workload patterns that exist in the VMware estate - stateless web services, scheduled batch jobs, long-running stateful services, databases, third-party software, internal tooling. For each pattern, the team defines how it lands on Kubernetes.
Once the patterns exist, individual workloads can be mapped to them. The migration of the fiftieth web service should be much faster than the migration of the first, because the path is defined. If it isn’t, the patterns haven’t been built.
A migration that treats each workload as a unique project is a migration that will take three to five years and produce an inconsistent estate. A migration that builds the patterns first compresses the timeline and produces consistency.
Migrate the operating model, not just the workloads
The most expensive thing inherited from a VMware estate is usually not the technology. It is the operating model: the way teams request infrastructure, the way changes are reviewed, the way capacity is planned, the way incidents are handled.
A Kubernetes platform that inherits all of these processes is not faster than the VMware estate it replaced. It is just a different way to run the same operating model. The migrations that produce strategic value redesign the operating model alongside the runtime change. Self-service replaces ticket queues. Standard patterns replace bespoke configurations. Continuous deployment replaces change windows.
This is the harder work, and it is where the strategic value of the migration actually lives.
Plan for the workloads that should not migrate
Some workloads should not move to Kubernetes. Workloads that are about to be retired, workloads where the licensing cost of the application is much higher than the VMware licensing cost, workloads where containerisation would require more engineering than the workload is worth.
A migration plan that does not explicitly identify the workloads that should not migrate ends up either migrating everything (and absorbing the cost of workloads that did not deserve the effort) or migrating selectively in a way that is unprincipled and hard to defend.
The conversation about what does not migrate is usually as important as the conversation about what does.
What Engineering Leaders Should Be Asking
If you are an engineering leader running or planning a VMware-to-Kubernetes migration, the questions worth asking are not about the migration itself. They are about the platform on the other side.
- What is the Kubernetes platform that the workloads will land on, and what capabilities does it have that the VMware estate did not?
- How many standard workload patterns are you defining, and what does each one look like on the platform?
- What does the operating model look like after the migration, and how does it differ from the VMware operating model?
- Which workloads are you not migrating, and why?
- What is the platform team’s capacity, and what fraction of the migration timeline is platform engineering work versus workload migration work?
- How will you measure whether the migration produced value beyond the licensing saving?
If these questions are hard to answer, the migration is at risk of producing a Kubernetes estate that looks like the VMware one, costs less in licensing, and reproduces most of the operational characteristics that motivated the migration in the first place.
The Window for Choosing Deliberately
The licensing pressure that started this wave is also what makes it hard to do well. Migrations driven by a renewal deadline tend to be migrations driven by cost, with the strategic platform work deprioritised because it is not on the critical path for the deadline.
The organisations that come out of this wave with strong Kubernetes platforms are the ones that treated the licensing pressure as a forcing function for a programme they would have wanted to do anyway. The organisations that come out with weak ones are the ones that treated it as an infrastructure replacement project.
The window for choosing which of those you are is usually open for the first six months of the migration. After that, the decisions taken under deadline pressure tend to harden into the operating model that will be in place for years.
The Takeaway
The VMware-to-Kubernetes migration is not the strategic event most organisations are treating it as. It is two events: a runtime change, and a platform engineering programme. The runtime change is the easy part. The platform engineering programme is what produces the value.
Organisations that recognise this early invest in the platform first, define patterns rather than migrations, and migrate the operating model alongside the workloads. They come out of the wave with a Kubernetes estate that is genuinely better than the VMware estate it replaced.
Organisations that recognise this late lift and shift onto Kubernetes, hit the licensing milestone, and discover that they have inherited every operational characteristic of the previous environment, in a more complex runtime, with an under-resourced platform team trying to operate it.
If you are in the planning phase of a VMware-to-Kubernetes migration and you want to be in the first category rather than the second, we can help you scope what that actually requires.