Cloud Migration Beyond Lift-and-Shift

"Lift-and-shift", moving applications to the cloud largely unchanged, is attractive because it is quick and predictable. It is also a way to take on a new bill while keeping every old problem: the same bottlenecks, the same single points of failure and the same manual operations. Better outcomes usually come from deciding, application by application, what the right destination is.

1. Assess before you decide

Inventory the applications, their dependencies, data volumes, traffic patterns, security and compliance requirements and the people who run them. Map which systems talk to which, because hidden dependencies and latency-sensitive connections decide what can move together. Measure current performance and availability so you have a baseline to improve on.

2. Choose a strategy per workload

A widely used framing sorts workloads into a handful of options:

• Rehost: move as is, for speed.
• Replatform: make targeted changes, such as a managed database, to gain benefits without a rewrite.
• Refactor: redesign parts of the application to use cloud-native capabilities such as queues, serverless functions or containers.
• Repurchase: replace with a commercial or software-as-a-service product.
• Retire: turn off what is no longer needed.
• Retain: leave in place for now, with a reason.

Most portfolios use several. Revisit the choice for critical systems, where a small amount of re-architecture can remove a major risk.

3. Prove the risky assumptions

List what must be true for the plan to work, such as acceptable latency to a data store, ability to replicate data across regions, throughput of a messaging service or compatibility of a legacy component. Build small proofs of concept for the riskiest items and measure them. A two-week proof that kills a bad assumption is far cheaper than discovering it during cutover.

4. Design for resilience

Agree on recovery time and recovery point objectives with the business, then design to meet them: deploy across availability zones, replicate data appropriately, use managed services that handle failover and test the failure modes on purpose. Event-driven services, queues and streams can decouple components so that one slow or failing part does not cascade. Remember that replication and consistency choices have trade-offs, so pick them deliberately for each data set.

5. Establish a secure foundation

Before moving workloads, set up the landing zone: accounts and environments, networking, identity and access management, logging, encryption, guardrail policies and cost visibility. This is easier to do once than to retrofit across dozens of applications, and it is where compliance requirements are largely satisfied.

6. Automate with infrastructure as code

Define networks, compute, storage and permissions in code using tools such as Terraform or CloudFormation, with review and testing like any other software. This makes environments reproducible, reduces manual error and gives you an auditable record of changes. Combine it with automated build and deployment pipelines.

7. Migrate in increments

Start with a low-risk application to prove the process, then move in waves. Migrate data with an approach that minimizes downtime, such as replication followed by a short cutover, and rehearse it. Keep rollback options open until the new environment has proven itself.

8. Control cost and operate well

Cloud costs follow usage, so tag resources, set budgets and alerts, right-size and review regularly. Update runbooks, monitoring and on-call practices for the new environment, and train the team that will run it.

The goal

A successful migration is not measured by how many servers moved. It is measured by whether the platform is more reliable, secure, adaptable and cost-aware than before.

This article offers general engineering perspective. It does not describe a specific client engagement.