Moving to the Cloud
Most organizations don't start in the cloud. They have existing systems — years or decades of software running on their own servers in a data center they own or lease. At some point they face the question: how do we move this to the cloud?
The answer is rarely "all at once" and almost never "rewrite everything." Cloud migration has a vocabulary — three strategies that sit on a spectrum from minimal change to full redesign — and leaders use these terms constantly. Knowing them lets you follow the conversation and understand the trade-offs being discussed.
The analogy: imagine relocating a shop to a new building. You could move everything exactly as it is into the new unit, carrying each shelf and display stand and placing it in the same position (lift-and-shift). Or you could tidy a few things while moving — replace a broken cabinet, rearrange a layout that never worked (re-platform). Or you could treat the move as a chance to completely redesign the shop for the new space and its customers (re-architect). Same destination, three very different amounts of work.
Lift-and-Shift (Rehost)
Lift-and-shift, also called rehosting, means moving existing systems into the cloud as they are — without changing the software or architecture. The same application, the same configuration, now running on rented machines instead of owned ones. This is the fastest path to the cloud and the lowest-risk option.
The catch: a lifted-and-shifted system gets very few of the cloud's benefits. It doesn't auto-scale. It doesn't use managed services. It doesn't take advantage of elasticity. You're now paying for a cloud but using it like an old data center. The move gets you off aging hardware and onto a provider's infrastructure — a real benefit — but the deeper gains come only if you go further.
Re-Platform
Re-platforming means making a handful of targeted improvements on the way — not a full redesign, but smart modernization steps. For example: swap a self-hosted database for a managed database service, or move a file archive to object storage. The application's core logic stays the same; only specific pieces are replaced with cloud-native equivalents.
Re-platforming picks up meaningful cloud benefits without the risk and cost of a full redesign. It's the middle path: more payoff than lift-and-shift, less disruption than re-architecting.
Re-Architect (Refactor)
Re-architecting, sometimes called refactoring, means redesigning the system to be cloud-native from the ground up. This is the highest-effort, highest-payoff option. A monolithic application (one large program that does everything) might be broken into microservices. New cloud-native patterns — stateless servers, auto-scaling, Infrastructure as Code — are adopted throughout.
Re-architecting unlocks the full value of the cloud: maximum elasticity, minimum operational overhead, and a system that can be changed quickly. But it takes months or years and requires significant engineering investment. Most organizations re-architect only their most important systems, and do it gradually.
Why Not All-or-Nothing?
Cloud migration is almost always phased. An organization might lift-and-shift a legacy payroll system (low priority, high risk to touch), re-platform their internal tools (quick wins), and re-architect their customer-facing product (highest value). Different systems get different strategies based on their importance, age, and how much they'd benefit from redesign.
All three major providers offer tools and programs to support migration — automated discovery of existing workloads, migration planning tools, and dedicated support teams. But the strategy choice is provider-neutral: the lift-and-shift / re-platform / re-architect spectrum applies regardless of which cloud you're moving to.
- "Moving to the cloud means rewriting everything." Lift-and-shift explicitly doesn't. Many organizations run lifted systems in the cloud for years without touching the code.
- "Lift-and-shift gives you all the cloud benefits." It gets you off your own hardware and onto a provider's infrastructure. That's it. Auto-scaling, managed services, and elasticity come only with re-platforming or re-architecting.
- "Migration is a one-day switch." For all but the smallest systems, migration is planned and phased over months — sometimes years. Moving piece by piece reduces risk and keeps existing systems running while the new ones are being set up.
- "Re-architecting is always the right answer." The right strategy depends on the system's age, importance, and business value. Some legacy systems are best left alone on a simple lift-and-shift; not every system justifies a full redesign.
- Cloud migration is where enormous organizational budgets and management attention go; the vocabulary — lift-and-shift, re-platform, re-architect — is essential for following those discussions.
- Understanding the trade-off between effort and payoff at each strategy lets you ask the right questions when an organization's migration plans are on the table.
- Knowing that migration is typically phased (not a big-bang switch) changes how you think about cloud adoption — it's a multi-year journey, not a single event.
Knowledge Check
What does "lift-and-shift" mean in cloud migration?
- Moving an existing system to the cloud as-is, without changing the software or architecture
- Redesigning a system from scratch to use cloud-native patterns like microservices
- Replacing specific components with managed services during the migration">Replacing specific components with managed services during the migration
- Moving only the newest parts of a system and leaving old parts on-premises">Moving only the newest parts of a system and leaving old parts on-premises
An organization moves its customer database from a self-managed server to a managed database service, while leaving the rest of the application unchanged. Which strategy is this?
- Lift-and-shift, because most of the application was unchanged
- Re-platforming, because one component was swapped for a managed service
- Re-architecting, because a cloud-native service was introduced
- None of these — this is a custom strategy without a name">None of these — this is a custom strategy without a name
Why is cloud migration almost always done in phases rather than all at once?
- Cloud providers can only accept one workload at a time, so phasing is required by their systems">Cloud providers can only accept one workload at a time, so phasing is required
- Phased migration costs less money than a single large move">Phased migration always costs significantly less money than a single large move
- Moving piece by piece reduces risk and keeps existing systems running while new ones are being set up
- Each strategy must be completed in order: lift-and-shift first, then re-platform, then re-architect">Each strategy must be completed in order: lift-and-shift, then re-platform, then re-architect
You got correct