Beyond VM migration: What comes after the lift-and-shift

I've had this conversation dozens of times with infrastructure teams. They've just finished, or are deep into, a VM migration off a legacy hypervisor. The hard part is nearly done. Or, so they think.

Here's the thing most people don't talk about: migration itself is the easy part. It's tactical. It has a clear beginning, middle, and end. What comes after, actually modernizing how you run your infrastructure, that's where the real work lives, and honestly, where most of the value is.

The industry shifts driving these migrations represent a strategic opportunity for modern infrastructure. By addressing licensing efficiency, cost optimization, and vendor flexibility, organizations are choosing Red Hat OpenShift Virtualization at an unprecedented rate, with customer adoption surging 178% since the start of 2024. While many discussions focus solely on the act of migrating, the true value lies in the innovation that happens after the move.

Instead of viewing migration as the final goal, forward-thinking organizations see it as the launchpad. This transition isn't just about solving past challenges—it’s about helping you build a foundation where you can fully take advantage of the capabilities of a modern, unified application platform that is ready for the future.

Here's what that broader roadmap looks like in practice.

Stage 1: Get your Linux house in order

After migration, you should consider evaluating your OS sprawl. Most organizations carry a mix of distributions, versions, and support contracts which accumulated over years of organic growth rather than deliberate choice. Now, to be clear: As an open source company, we’re not here to tell you that monocultures are always the answer. Heterogeneity has genuine benefits. It can reduce shared failure modes and limit blast radius from a single defect class. Some of that diversity is intentional and defensible.

But in large companies, a lot of it isn't. It's technical debt. It's the Ubuntu instance someone spun up for a project in 2019 that's now running something critical. It's the CentOS box that nobody patched after the end of life (EOL) announcement. It's the Windows XP that no one really knows what it does, but if it goes off line you're in trouble.

Once you've standardized the hypervisor layer, the next natural step is looking at your guest OS landscape. Running Red Hat Enterprise Linux (RHEL) alongside Red Hat OpenShift gives you a more consistent operational model—unified patching, coherent support paths, and policy enforcement that actually works across your environment. The 2024 Global Tech Trends Red Hat survey found that 45% of businesses put modernizing their application stack at the top of their list. The modernization efforts that actually work all followed the same principle: get rid of the OS diversity that isn't justified, and hold onto those that have a valid business case.

Stage 2: Stop managing the new platform like the old one

This is the mistake we see most often. Teams complete a migration and then keep managing the new environment exactly the way they managed the old one. Same manual processes. Same ticket-driven patching cycles. Same ad-hoc changes through a console.

The post-migration environment is a clean slate. It's probably the best opportunity you'll ever have to get your automation story right.

Red Hat Ansible Automation Platform is where teams can move from weeks of manual rollout work to hours. Once the playbooks are in place, provisioning, patching, and compliance just happen.

If your team already lives in GitOps territory, Red Hat Advanced Cluster Management for Kubernetes brings that same discipline to virtualization. Policy becomes code, stored in Git. No more console-driven drift. That means tighter drift control, faster rollouts, and more predictable Day 2 operations.

Here's the practical truth: automation isn't a nice-to-have on the modernization path. It's what makes the later stages possible at all.

Stage 3: Run workloads where they actually belong

Not every workload should stay a virtual machine (VM) forever. Some are natural fits for containerization. But the goal is not to containerize everything. The goal is to run each workload where it makes the most sense.

OpenShift lets you manage VMs and containers on the same platform, which means you don't have to choose between "lift-and-shift everything" and "rewrite everything as cloud-native." That false binary has wasted a staggering amount of time and money across this industry. PNC Bank is a good example of doing this pragmatically. They adopted new standards and cut delivery time from 8 weeks with a target of 10 days.

This stage is where a lot of teams stall. The technology isn't the hard part. The hard part is figuring out which workloads move, when, and in what order. Having someone who's been through it before can make the difference between a 6-month modernization cycle and a 13-month one. Forrester's research bears this out. A composite organization shortened their OpenShift deployment and VM migration from 13 months to 7 with experienced guidance.

Stage 4: Think about AI before you need to

Here's the thing about AI: nobody who successfully rolled it out retrofitted it onto infrastructure that was already a mess. Gartner® says worldwide AI spending will total$2.5 trillion in 2026.

I'm not saying plan for AI before you finish the migration. But the teams I've seen do this well had one thing going for them: clean, automated infrastructure underneath. AI workloads are picky about compute, storage, and observability. You'd rather solve that on a standardized Kubernetes-native platform than untangle it from years of organic growth.

Migration moves you. Modernization transforms you.

Migration moves you away from a platform you didn't want to stay on. Modernization builds the platform you actually need. Those are fundamentally different things, and the gap between them is where the real work (and the real value) lives.

Gartner Press Release, Gartner Says Worldwide AI Spending Will Total $2.5 Trillion in 2026, January 15, 2026

GARTNER is a trademark of Gartner, Inc. and/or its affiliates.