Lift and Shift vs Re-Architect: Choosing the Right AWS Migration Strategy

Lift and Shift vs Re-Architect: Choosing the Right AWS Migration Strategy

The most common migration mistake is picking a strategy for the project rather than for each workload. "We're lifting and shifting everything" and "we're going cloud-native" are both wrong answers. They are budget and timeline positions masquerading as technical decisions.

The right strategy depends on what each workload does, how long it needs to run, and what you actually gain by changing it.

The Six Rs: A Practical Summary

AWS describes migration strategies as the "6 Rs." Four of them matter in practice:

Rehost (lift and shift): Copy the workload to AWS infrastructure without changing it. An on-premise VM becomes an EC2 instance. The application does not know it moved.

Replatform: Make targeted changes to take advantage of managed services, without re-architecting the application. Move from self-managed MySQL to Amazon RDS. Move from a self-managed message queue to Amazon SQS. The application changes slightly; the architecture does not.

Refactor/re-architect: Redesign the workload to use cloud-native services. Break a monolith into services, move batch jobs to Lambda, use Aurora Serverless instead of provisioned RDS. High effort, high long-term payoff.

Retire: Decommission the workload instead of migrating it. Often the highest-value decision in the entire exercise.

The other two (retain, repurchase) are edge cases: retain means leaving the workload on-premise; repurchase means replacing it with a SaaS product.

When Lift and Shift Is the Right Call

Lift and shift is underrated. It has a reputation as a lazy approach, but laziness is not the point. Speed and risk reduction are the point. Rehosting is the right choice when:

The timeline is tight. Rehosting is faster than re-architecting by an order of magnitude. If a datacentre contract is expiring, if a hardware refresh is due, or if there is a hard regulatory deadline, lift and shift moves the workload out of the problem.

The application is stable and low-risk. If nobody is actively developing the workload, re-architecting it creates unnecessary risk and consumes engineering capacity with limited return.

You are acquiring AWS experience. If your team has limited AWS operations experience, starting with rehosted workloads builds familiarity with the environment before you take on cloud-native complexity.

The workload is earmarked for retirement. Do not re-architect something you plan to replace in 18 months. Rehost it to clear the datacentre obligation and decommission it when the replacement is ready.

The honest case against lift and shift: you move the workload without gaining most of the cloud benefits. You still pay for idle infrastructure. You still manage patching. You still run a fixed-capacity model. Lift and shift is a migration, not a transformation.

When Re-Architecting Pays Off

Re-architecting is justified when the workload is:

Strategically important and actively developed. If engineers are shipping to this system weekly, re-architecting to cloud-native patterns pays compound dividends. Managed services reduce operational overhead, auto-scaling handles variable demand, and serverless components eliminate idle capacity costs.

Constrained by on-premise architecture. Some workloads cannot scale on their current architecture. A monolithic application hitting database connection limits, a batch job that needs burst compute far beyond on-premise capacity, or a service where cold starts have become a user experience problem: these are candidates for genuine re-architecture.

Carrying compliance obligations that cloud-native controls satisfy better. Encrypted-at-rest storage, fine-grained IAM policies, CloudTrail audit logging, GuardDuty threat detection: these capabilities are native to AWS. Lifting and shifting leaves them as bolt-ons. Re-architecting makes them structural.

The honest case against re-architecting everything: it is expensive, slow, and risky. The engineering effort that goes into re-architecting a workload is engineering effort not going into new product capability. The disruption to the application during refactoring creates regression risk. Many refactoring projects run over time and over budget.

Replatforming: The Middle Path That Gets Overlooked

Replatforming is where the best migration ROI often lives, and it is the least-discussed option.

Moving from self-managed Postgres on EC2 to Amazon RDS is not a re-architecture. The application does not change. You gain automated backups, multi-AZ failover, managed patching, and performance insights. The operational burden drops substantially.

The same logic applies to:

• Self-managed Redis on EC2 to Amazon ElastiCache
• On-premise message queues to SQS or Amazon MQ
• Custom log aggregation to CloudWatch Logs or Amazon OpenSearch
• Self-managed Kubernetes to Amazon EKS with managed node groups

Replatforming targets operational pain without application risk. For most regulated businesses running mature applications, it is the right default for the middle tier of the workload portfolio: not important enough to re-architect, too operationally costly to simply rehost.

A Framework for Deciding Per Workload

For each workload in scope, work through four questions:

How actively developed is it? Active development favours re-architect. Stable or declining activity favours rehost or retire.

What is the operational cost of running it now? High operational cost (manual patching, scaling toil, fragile infrastructure) favours replatform or re-architect. Low operational cost means the case for change is weaker.

What is the risk of changing it? Complex dependency maps, unclear ownership, sparse test coverage, and regulatory touchpoints all increase change risk. Higher risk favours rehost or replatform over re-architect.

What is the strategic horizon? Workloads with a clear replacement roadmap in the next two years should be rehosted or retired. Workloads that will run for five-plus years deserve the investment of re-architecting.

Most portfolios, when worked through honestly, split roughly into thirds: a third rehost, a third replatform, and a third somewhere between replatform and re-architect. Pure lift and shift and pure re-architect are both minority answers.

Migration Wave Sequencing

The strategy decision also affects wave sequencing. A useful default order:

1. Rehost non-production environments first. Low stakes. Builds operational familiarity with AWS. Tests your connectivity and IAM model.
2. Rehost simple production workloads. Gets volume into AWS quickly. Validates your landing zone configuration under real load.
3. Replatform production workloads. Database migrations, queue migrations, cache migrations. One service type at a time.
4. Re-architect strategic workloads. With the rest of the portfolio stable in AWS, engineering focus is available for the high-effort work.

Running re-architecture in parallel with early migration waves is almost always slower than it looks. The team gets pulled to operational issues in the new environment before the re-architecture is complete.

What Observability Has to Do with It

Migration strategy and observability strategy are not separate decisions. Every workload moving to AWS needs instrumentation from day one, regardless of migration pattern.

Rehosted workloads need the same infrastructure metrics, log collection, and alerting as cloud-native ones. The Datadog agent runs on EC2 as naturally as it runs on a Kubernetes pod. Replatformed workloads gain access to RDS Performance Insights, ElastiCache metrics, and SQS queue depth: all visible in a single Datadog dashboard alongside the application layer.

The worst time to realise your observability model does not cover the migrated workload is during the first production incident after migration.

Where Critical Cloud Comes In

Choosing the right migration strategy per workload, sequencing waves to manage risk, and ensuring observability is in place throughout the process is what separates a successful migration from one that costs twice as much and takes twice as long.

Critical Cloud runs structured AWS migrations for technology-led businesses, with Datadog observability integrated from the first workload. If you are planning a migration and want to get the strategy right before committing the engineering effort, see how our FETCH engagement works.