When “Lift & Shift” Isn’t a Mistake: Rethinking Cloud Migration Strategies

I came across a LinkedIn post that criticized lift & shift as a poor modernization strategy because it doesn’t change UX, architecture, or workflows. These points highlight concerns many experts have: that lift-and-shift migrations can miss opportunities for greater improvements, lock in outdated practices, or create technical debt if not followed by modernization efforts. I want to offer a different perspective. I don’t think “Lift & Shift” is always a mistake. It only becomes one if that’s where the process stops.

The real problem isn’t lift & shift itself. It’s when people confuse migration with true modernization.

Why Lift & Shift Can Be a Smart First Step

For many enterprises, lift & shift is often used as an intentional first step.
• It helps stabilize aging systems,
• Move away from costly or limited infrastructure,
• Buys time to rethink architecture without disrupting business operations.

Not every organization can afford to redesign processes, UI, and integrations before making a move. Sometimes, it’s necessary to create a safer landing zone first.

When Is Lift & Shift the Right Choice?

There are certain cases where a lift & shift approach makes the most sense. For example, if an organization is facing an urgent need to exit outdated or unsupported infrastructure, has limited resources to dedicate to a full-scale redesign, or has to prioritize business continuity instead of innovation in the short term, lift & shift affords a viable way forward. It can also be the right choice when tight regulatory deadlines require a quick migration, or when there are major risks involved in changing complex legacy systems all at once. Through evaluating these criteria, teams can determine when a lift-and-shift strategy matches their needs and constraints. The real problem isn’t lift & shift itself. It’s when people confuse migration with true modernization.

From Migration to Modernization: Next Steps

When done right, lift & shift should be the starting point for things like:
• Incremental refactoring,
• Enabling APIs,
• Redesigning processes.

I’d like to hear how others have tackled real challenges when balancing the need for quick migration with deeper modernization. In my experience, a good next step after lift & shift is to set up monitoring and automation tools in the new environment right away. This gives teams visibility and helps them spot where small improvements can make the biggest difference.

Another useful strategy is to focus on what matters most to the business. Pick a key workflow or component and refactor it as a pilot, then use what you learn to guide future phases. What challenges have you faced when modernizing systems after a lift & shift? What practical solutions have worked for you? I’d especially appreciate insights on how teams balance urgent business needs with planning for future improvements.

Conclusion: Turning Migration Into Modernization

Although some criticize lift & shift migrations for not bringing instant transformation, they can be a practical and necessary first step in a larger modernization effort.

The real value comes when organizations use this approach to quickly stabilize workloads, then invest in refactoring, automation, and process improvements.

By treating lift & shift as the start of modernization, not the finish line, businesses can move quickly while still aiming for bigger, lasting change in their IT environments.

This applies to your System and/or Data migration strategy.