The Quiet Collapse of the ‘Lift and Shift’ Era: What AWS re:Invent 2025’s Graviton4 Adoption Numbers Actually Mean

The Numbers Tell a Story Nobody Expected to Happen This Fast

AWS re:Invent 2025 dropped what should have been a quiet technical update buried somewhere between keynote applause and the endless booth demos. Instead, it landed like a small grenade in the middle of enterprise infrastructure planning: Graviton4-based instances now power over one-third of all new EC2 workloads, nearly double the 18% penetration from the year before. If you’re not paying attention to this, your CFO should be.

This isn’t a “nice alternative” story anymore. This is the moment when ARM architecture stops being the scrappy underdog that everyone promises will matter “eventually” and becomes the practical default for anything new. The kind of shift that doesn’t announce itself with fanfare. It just happens while you’re dealing with patch Tuesday or arguing about Kubernetes namespacing conventions.

What makes this genuinely interesting to me, after fifteen years of watching infrastructure trends cycle through hype, adoption, and eventual irrelevance, is the speed. We went from “ARM in the cloud is for startups and edge cases” to “ARM is the economically rational choice for the majority of new deployments” in roughly the time it takes to run three budget cycles. That’s not inevitable. That’s engineering and market forces converging into something that actually works.

The Economics Don’t Lie, and Neither Do the Benchmarks

The AWS Graviton4 instance performance benchmarks show up to 40% better price-performance on compute-intensive workloads compared to x86 equivalents in the same tier. That’s not marketing speak where “better” means “technically faster but costs more.” That’s 40% better price per unit of compute. That’s the kind of number that gets CFO eyeballs.

Run the math yourself on a medium-sized SaaS operation: if your annual EC2 bill is half a million dollars and you’re still exclusively on x86, you’re leaving roughly $110,000 on the table every single year just by making the wrong architecture choice. For a bootstrapped startup, that’s basically salary for another engineer. For a publicly traded company, that’s pressure from the board. Neither scenario is comfortable, and both are becoming more common as the quarters tick forward.

The key word there is “now.” These numbers weren’t true five years ago. Three years ago they were true for some workloads, maybe. But improved silicon, maturing orchestration, and ecosystem catch-up mean Graviton4 isn’t a “consider it for green-field projects” recommendation anymore. It’s “why are you still choosing x86 without a documented reason?”

The Ecosystem Excuse Has Officially Expired

Red Hat’s 2025 State of Linux report clocked a 94% year-over-year growth in RHEL on ARM64 deployments. That number matters because it signals something concrete: the ecosystem excuse is dead. Nobody gets to say “but our tools don’t support ARM” anymore without doing some actual homework first.

I spent years watching engineers justify staying on legacy infrastructure because “the monitoring doesn’t support ARM yet” or “our deployment tools are only tested on x86.” These were never technically sound arguments, but they were politically convenient ones. They solved the problem of having to change something that worked, even if it worked at premium price tags. That shield is gone now.

The software landscape has shifted dramatically. Containerization means your application code itself doesn’t care about architecture. The orchestration layer is mostly abstracted. Databases, caches, message brokers, observability stacks: they’re all ARM-ready. The only blocker now is organizational inertia, which is real but measurable and fixable.

The Real Problem: Lock-In and Re-Architecture Paralysis

Here’s where the story gets less satisfying but more true. The Flexera 2025 State of the Cloud Report found that 59% of enterprises still running lift-and-shift migrations reported x86 dependency lock-in as their primary re-architecture blocker. That’s not a technical problem. That’s an organizational one.

A lift-and-shift migration is what happens when you move a physical server wholesale into the cloud without meaningful re-engineering. You get a VM that looks exactly like your on-premises box, with all the same configuration choices, installed packages, and embedded assumptions. It works. It’s also expensive, inflexible, and extremely hard to migrate away from once you’re locked in. You can’t just “switch to Graviton” if you’ve got undocumented dependencies baked into the image.

The math gets worse when you realize organizations doing lift-and-shift are simultaneously paying an average 22% premium on annual compute spend compared to ARM-optimized alternatives, according to IDC’s Q3 2025 estimate. That’s not a rounding error. That’s genuine waste, the kind that accumulates year after year while the business case for fixing it gets harder to justify because you’d have to admit you’ve been doing it wrong.

What Actually Happens Next

The inflection point is real, but it’s not uniform. Three distinct patterns will likely emerge over the next 18 months. Greenfield projects will almost entirely default to Graviton unless there’s a specific incompatibility, and this is already happening. Workload-by-workload migrations will accelerate as teams get comfortable with the technical reality and the financial case becomes impossible to ignore. The remaining lift-and-shift operations will slowly become the infrastructure equivalent of technical debt: acknowledged, expensive, and steadily more embarrassing.

What I’m genuinely curious about is what happens after the easy migration is done. Once Graviton becomes the baseline and x86 becomes the exception you have to justify, we’ll finally have space to ask better questions about infrastructure design entirely. What if we didn’t assume monolithic virtualization? What if we optimized for the economics of our actual workload instead of trying to match some architecture decision from 2009?

The collapse of lift-and-shift isn’t a collapse at all. It’s a transition, and transitions are where the interesting work happens. What’s your infrastructure looking like in this new reality? I’d genuinely like to hear what you’re seeing.