VMware renewal season feels different this time around, and not just because of pricing. The conversations have a different weight to them. What used to be a relatively contained discussion inside the virtualization team is now pulling in platform engineering, finance, and senior leadership. Somewhere in that shift, something more important than licensing changed. Ownership moved.
You can debate what Broadcom did to VMware, whether the changes were overdue or disruptive, and whether the pricing reflects value or opportunism. That debate is happening everywhere. It is also not the most important thing going on. What matters is that the renewal cycle has forced organizations to look closely at their virtualization footprint, and when they do, the question quickly becomes who is responsible for it going forward. Increasingly, the answer is platform engineering.
At SUSECON 2026, that shift was already visible in how people were talking about infrastructure. When Peter Smails and Frank Feldmann described a unified control plane, they were not pitching a theoretical future. They were outlining what the next practical operating model needs to look like. Virtual machines and containers are no longer separate domains with separate tooling and separate teams. They are simply different workload types that need to be managed through the same platform, with consistent workflows, policies, and automation.
That has direct implications for internal developer platforms. Many IDPs today are built with Kubernetes at the center, and they do that job well. They provide golden paths, enforce standards, and give developers a self-service interface to modern infrastructure. The problem shows up the moment a VM enters the conversation. In most organizations, that still triggers a parallel process, different tooling, and a different team. At that point, whatever you call your platform, it is not a unified control plane. It is two systems that happen to coexist.
The reality of that gap becomes clear very quickly once the renewal conversation moves from pricing to action. In the early stages, the focus is on cost, contracts, and timelines. Within a couple of months, the focus shifts to movement. What workloads can be migrated, what needs to stay, and how quickly anything can realistically change. This is where platform engineering teams start to feel the pressure, because they are expected to provide a path forward even when their current platform was never designed to handle virtual machines as first-class citizens.
This is also where the importance of automation comes into sharper focus. Migration is not just a one-time project. It is a process that needs to be repeatable, auditable, and integrated into the same operational model that handles everything else. Without that, organizations end up recreating the same fragmentation they were trying to escape, just under different branding. The gains people expect to see in the total cost of ownership do not come from the initial switch. They come later, in day-to-day operations, when environments are consistent, policies are enforced centrally, and teams are not maintaining parallel systems with different rules.
There are already examples pointing in this direction. Aussie Broadband approached this as a platform problem rather than a virtualization refresh, which allowed them to rethink how workloads are managed rather than just where they run. The combination of SUSE Virtualization and Dell storage is another signal that the ecosystem is aligning around this idea of a unified control plane. These are not isolated experiments. They reflect a broader shift in how infrastructure is being structured and operated.
The larger implication is hard to ignore. The internal developer platform is expanding beyond its original scope and becoming the control plane for the entire compute estate. If it cannot manage both containers and virtual machines, then organizations are effectively running two platforms. That duplication shows up in duplicated effort, inconsistent policy enforcement, and increased operational risk. Over time, that becomes harder to justify, especially when the business expects a single, coherent platform experience.
There is also a people dimension that does not get enough attention. Virtualization teams have deep operational knowledge that has kept critical systems running for years. As platform engineering takes on more responsibility, those teams are not disappearing, but their role is changing. If they are not brought into the platform conversation in a meaningful way, organizations risk losing valuable expertise at the exact moment they need it most. This transition works best when it is treated as a convergence of disciplines rather than a replacement of one by another.
What is happening right now is not the end of virtual machines. It is the end of treating them as a separate world. The boundaries that once made sense between virtualization and cloud native infrastructure are dissolving under the pressure of cost, scale, and operational complexity. Platform engineering sits at the center of that change, whether it was planned that way or not.
VMs are not going away. The lock-in around them is. Those are not the same thing.