Lift and Shift Isn’t Transformation
Most organizations don’t fail in the cloud—they stall. The problem isn’t migration. It’s what comes after.
I’ve been part of the cloud journey for a long time now. I’ve seen the early adopters go all in—moving fast, embracing the shift, and figuring things out as they went. I’ve also seen the late adopters, who are still trying to reconcile how to move from capital budgets to operating expenses while adapting to the consumption-based pricing models that nearly every vendor is pushing toward.
What stands out to me is how familiar this all feels.
The Pattern We Keep Repeating
I saw it back when we moved from hand-built data centers to cloud infrastructure. The conversations were different, the technology was different, but the underlying challenges weren’t. We traded one model for another, but in many cases, we carried the same thinking with us.
And that’s where things start to break down.
Most organizations don’t fail in the cloud. They stall.
Lift and shift feels like transformation.
But most of the time, it’s just relocation.
The Illusion of Progress
A migration plan gets approved, timelines are tight, and risk needs to be minimized. So the decision gets made: lift and shift. Move what exists, keep it stable, and call it progress.
On paper, it works.
Systems are running. Applications are in the cloud. The box gets checked.
But then something uncomfortable happens.
Nothing actually changes.
Same systems. Same dependencies. Same friction—just in the cloud.
Same problems.
New environment.
Different cost structure.
Why Lift and Shift Happens
There are real reasons organizations choose this path. It checks the box, reduces perceived risk, and fits aggressive timelines. In many cases, it’s a necessary first step.
But it becomes a problem when it becomes the end state.
Because the hard work was never the migration.
The hard work is what comes next.
The Question That Gets Avoided
Most cloud conversations focus on where things run, what services to use, and how fast we can move. But they avoid the question that actually matters:
What needs to change?
Not infrastructure.
The system. The dependencies. The way teams build, deploy, and operate.
Transformation isn’t about where it runs.
It’s about how it’s built.
What Transformation Actually Requires
Transformation means breaking dependencies instead of preserving them, rethinking architecture instead of copying it, and changing how teams work—not just where workloads run.
This is where most efforts slow down.
Because this is where the organization—not just the technology—has to evolve.
Cloud Doesn’t Transform You
Cloud doesn’t create transformation. It’s the forcing function. It reveals whether an organization is willing to do the work.
Once everything is visible—costs, inefficiencies, bottlenecks—you can’t hide behind the environment anymore.
Cloud doesn’t transform your business.
It exposes whether you’re willing to.
Experience Is the Differentiator
This is where experience starts to matter. Not just knowing what can be done, but knowing what actually needs to change, what can be left alone, and what will create real impact.
That’s the difference between movement and progress.
Lift and Shift Is a Phase
There’s nothing inherently wrong with lift and shift. In many cases, it’s the right starting point. But it was never meant to be the destination.
Cloud doesn’t transform your business. It gives you the opportunity to.
What you do next is what determines whether anything actually changes.
These are some of the themes I explore in Finding Direction in the Age of AI—where technology is accelerating, but experience still defines the outcome.