Beyond ‘Lift and Shift’: Why KubeVirt Makes ‘Move and Improve’ Actually Possible

This is Part 1 of a two-part series on KubeVirt and the move and improve approach to VM modernization.

For over a decade, “lift and shift” has been the default entry point for enterprises moving to the cloud. The pitch was simple: pick up your existing virtual machines (VM), drop them into a cloud provider, and deal with modernization later. It was supposed to be step one of a two-step journey—move now, improve later, once you had breathing room.

In practice, that second step rarely happens. I think there is a new path—one where “move and improve” isn’t a slogan you say and quietly abandon, but something the architecture makes possible from day one.

Two paths, one common problem

The first is building deliberate hybrid cloud strategies—putting the right workload in the right place, keeping some systems on premises for latency, compliance, or cost reasons, and running others in the cloud where elasticity and managed services add real value. The second camp has made a different call: move fully to the cloud, often driven by a data center exit, a lease expiration, or a broader strategic mandate. These organizations typically have a large existing virtualization estate—very often VMware—that has to go somewhere.

Both groups run into the same wall eventually: The traditional lift-and-shift model was never actually designed to deliver “improve.” It was designed to deliver “move.” 

The broken promise of ‘move now, improve later’

The story usually goes something like this: rehost your VMs onto cloud-native virtualization services, get everything running, and then—once things have stabilized—begin re-platforming, containerizing, and modernizing at your own pace.

• Rebuilding VM infrastructure is a full project on its own. Getting workloads running as native cloud VMs requires re-architecting networking, security groups, identity, image management, and monitoring—essentially reassembling a virtualization platform from parts, using unfamiliar tools.
• Costs and retooling compound. New licensing models, automation stacks, operational runbooks, and staff training all show up as real, sustained costs—not one-time migration costs.
• Governance never gets simpler. High availability (HA), disaster recovery (DR), backup, and automation behave differently in native cloud VM services than they did in VMware. Policies, runbooks, and compliance controls have to be redesigned and revalidated against tooling that doesn’t map cleanly to years of VMware operations.
• The “improve” phase keeps getting pushed out. Teams get consumed by keeping the lifted environment stable and compliant, while the strategic bandwidth needed to modernize gets absorbed by operational overhead—often for years, not months.

The cruel irony is that all of this effort is spent recreating a virtualization environment—the very thing enterprises were often trying to get away from in the first place.

The real question: What is cloud infrastructure for?

This is where it’s worth stepping back and asking what the actual goal of moving to the cloud is. It was never to build another large-scale, standalone virtualization estate. Cloud value comes from connective tissue—linking workloads to Kubernetes-native applications, managed services, elastic scaling, and modern operational tooling.

Native cloud VMs, on their own, don’t get you there. They get you a VM that runs somewhere else. The bigger issue is that they keep VMs in a separate operational model rather than putting them alongside the Kubernetes-native applications, managed services, and tooling you’re ultimately moving toward. It’s effort spent standing still, dressed up as progress.

Why KubeVirt changes the equation

KubeVirt flips this model by running your existing virtual machines as native workloads inside Kubernetes, rather than as a separate virtualization layer sitting next to it. Instead of migrating a VM off VMware and into another siloed VM service, you migrate it directly onto the same Kubernetes control plane, networking model, and operational stack you’re using—or plan to use—for your containerized and cloud-native applications.

• HA, DR, backup, and automation converge onto one platform. You’re no longer maintaining two parallel operational models—one for VMs, one for containers. Kubernetes’ existing primitives extend to your VMs. 
• The “improve” step becomes incremental, not a second migration. Once a VM lives in Kubernetes, moving pieces of that application toward containers, sidecars, or managed services is a natural next step on the same platform.
• Governance is unified from day one. Policies, Role-Based Access Control(RBAC) observability, and compliance controls are defined once, in Kubernetes terms, and apply across both VM and container workloads.

This is the real shift: Move and improve stop being two separate phases with a gap between them and become one continuous motion. You’re placing the VM directly onto the platform where modernization is a native, ongoing capability—not a future project competing for resources against everything else on the roadmap.

Figure 1: From “lift and shift” to “move and improve.”

‘Hold my beer’: KubeVirt and the technical debt VMware built

There’s a line that circulates among infrastructure veterans: VMware is one of the biggest contributors to application improvement technical debt in the world. It’s a joke, but it’s not really a joke. VMware’s greatest strength—rock-solid backward compatibility and best-in-class infrastructure resiliency—also made it easy to never touch an old application again. Why modernize a fragile, ancient app when VMware’s HA, DR, and vMotion could make it enterprise-grade resilient anyway? VMware didn’t just tolerate legacy applications. It quietly subsidized their survival for 20 years.

KubeVirt looks at that legacy and says, essentially, “hold my beer.”

It allows those same legacy VMs to move onto Kubernetes without touching the application at all—no refactor, no re-platform, no forced upgrade. The app inside the VM never has to know anything changed.

But here’s the crucial difference, and it’s the whole point: The infrastructure underneath is no longer frozen in place along with the app. Your infrastructure team can move the platform forward—standardize on Kubernetes, adopt modern automation, converge tooling with the rest of the cloud-native estate—while that crusty legacy VM rides along, blissfully unaware, still doing its job.

That’s the win. You’re not incentivized to fix the app before you can improve the infrastructure, and you’re not stuck rebuilding the infrastructure just to accommodate the app. The technical debt doesn’t vanish—legacy apps are still legacy apps—but for the first time, it’s contained. It stops being an anchor on your modernization strategy and becomes  something you can deal with on its own timeline.

Figure 2: One platform for VMs and cloud-native applications.

Don’t wave goodbye to thin provisioning

There’s a financial dimension to all of this that often doesn’t surface until the first cloud bill arrives, and it’s a big part of why lift and shift so often can end up costing more than the data center it was supposed to replace.

In your own data center, your VM sizes are whatever you need them to be—a specific memory-to-CPU ratio, a particularNetwork Interface Card( NIC) speed, some odd combination that fits the actual application. Native cloud VM services don’t work that way. You’re choosing from a fixed catalog of instance families and sizes, and your sprawling, idiosyncratic mix of on-prem VM shapes almost never maps cleanly onto them. You end up rounding up—paying for more CPU or memory than the workload needs—because the exact shape you run simply isn’t sold. Or rounding down, which can lead to application performance impact. Choose your poison.

The bigger issue sits underneath that one. In your own data center, hypervisor-level oversubscription—running more virtual CPU and memory than the physical hardware technically supports because workloads rarely hit peak simultaneously—is value that accrues to you. It’s a big part of the reason VMware environments run efficiently at scale. With native cloud VMs, you pay for what you provision, not what you use. The oversubscription math doesn’t disappear, it just accrues to the cloud provider’s margin instead of your bill. That’s a structural, not incidental, cost increase. KubeVirt doesn’t eliminate cloud economics, but it puts VMs back inside a scheduler—Kubernetes—that’s designed for bin-packing and resource sharing across workloads, rather than forcing every VM into a rigid, pre-priced instance shape. That’s a meaningfully different cost posture than renting fixed-size boxes one at a time.

Every native cloud VM migration—AWS to Azure, on-prem to cloud—has traditionally meant re-encountering the same painful list: different networking constructs, different HA/DR models, different automation tooling, different compliance mappings. Each move was effectively a re-migration, with its own budget, its own risk, and its own multi-month timeline.

KubeVirt collapses that problem, because the VM was never really tied to a specific cloud’s virtualization service in the first place (or even really a vendor)—it’s tied to Kubernetes. And Kubernetes, by design, looks the same whether it’s running on-prem, at a hyperscaler, or at a different hyperscaler entirely. Move the workload from one Kubernetes cluster to another, and the VM comes with it as is: same definitions, same networking model, same HA/DR/backup policies, same automation. No refactoring. No re-architecture. For multi-cloud enterprises, this is what genuine optionality looks like: Today’s “right place for the right workload” decision doesn’t have to be permanent. If pricing shifts, a new region opens up, a merger changes the estate, or a strategic decision reroutes the roadmap, the workload can move again without triggering another full migration cycle. The cloud choice stops being a one-way door and starts being a decision you can actually revisit.

What about just running VMware in the cloud?

It’s worth addressing the option that sits between “native cloud VMs” and “stay on-prem forever,” because it’s a real and reasonably popular choice: run VMware itself in the cloud, via something like Amazon Elastic VMware Service, Azure VMware Solution, or the equivalent from Nutanix (NC2) on AWS or Azure, etc.

Those are fantastic options for persistent hybrid cloud—keep the architecture consistent. But for migration, less so.

But it’s worth being honest about what it actually is: a relocation, not a resolution. The VMware estate is now running on rented hardware instead of owned hardware, but it’s still a separate, self-contained virtualization silo—parallel to, not integrated with, whatever Kubernetes-based and cloud-native investment the rest of the organization is making. It still needs to be run, patched, licensed, and governed as its own environment. It doesn’t get you closer to containers, managed services, or the connective tissue that was the actual point of moving to the cloud. 

And critically, it doesn’t remove the obligation to eventually do something about it. The “next step” hasn’t been eliminated—it’s been deferred, again, at the cost of running two fully separate infrastructure stacks side by side: one for VMs, one for everything cloud-native. That’s a legitimate bridge for some organizations. It is not, on its own, the destination. 

This isn’t theoretical—it’s available today, on the cloud you’re already choosing

Figure 3: Move VMs across clouds without rebuilding the stack.

On Azure, Red Hat and Microsoft have co-engineered OpenShift Virtualization directly into Azure Red Hat OpenShift (ARO)—a jointly managed offering, not a bolted-on side project. It’s purpose-built as the supported path for customers moving off legacy virtualization while modernizing at their own pace.

On AWS, the equivalent path runs through Red Hat OpenShift Service on AWS (ROSA), self-managed OpenShift, or upstream KubeVirt on EKS or AKS. OpenShift Virtualization is an officially supported capability across Red Hat’s managed offerings, already running in production.

So the question isn’t whether “move and improve” is possible. It’s already running, on infrastructure you can provision this quarter. The only question left is whether your next migration recreates the same VM silo you tried to leave—or finally puts your VMs on the platform where “improve” was always supposed to happen.

If you’re planning a cloud migration, this is the conversation worth having before the migration plan gets locked in. KubeVirt is a direct step in the longer-term aspiration of modernizing that app too. You’ve done half the work: you’ve modernized its ecosystem.