Lift and Shift vs Replatforming vs Refactoring: Which Migration Strategy Should You Choose?

A cloud migration is a portfolio of decisions

A cloud migration is not a single technical decision. It is a portfolio of decisions about risk, speed, cost, product capability, and the operating model needed once systems are live.

The three strategies most often considered are lift and shift, replatforming, and refactoring. Each can be the right choice. Problems arise when an organisation applies one approach to every workload, treats migration as an infrastructure move alone, or assumes that arriving in the cloud automatically delivers lower cost and better agility.

AWS groups these approaches within its wider “7 Rs” migration framework: rehost, replatform, refactor, relocate, repurchase, retire, and retain. In practice, a large programme commonly uses several strategies across different applications and sometimes within the same application. AWS Prescriptive Guidance makes this distinction clear: the strategy should follow the workload’s needs, not a blanket cloud policy.

The question is not “Which strategy is best?” It is: “What is the lowest-risk path to the business outcome this workload must support?”

The three strategies at a glance

A sensible migration programme begins with discovery: application ownership, technical dependencies, data classification, performance needs, support status, release cadence, and business criticality. That discovery should shape both the target architecture and the migration waves.

Lift and shift (rehosting): move first, change later

Lift and shift, formally called rehosting, moves an application from its existing environment to cloud infrastructure with minimal changes to the application itself. A virtual machine estate may move to Amazon EC2, for example, while retaining the same operating systems, middleware, topology, database engine, and deployment process.

This is often the right response when time matters. Perhaps a data-centre exit date is fixed, ageing hardware creates operational risk, an acquisition has created duplicate infrastructure, or an organisation needs to reduce exposure to an unsupported hosting environment. It can also be appropriate for commercial off-the-shelf software where vendor support constrains architectural changes.

The attraction is obvious: fewer code changes reduce the number of things that can break during migration. Teams can sequence large volumes of servers through repeatable migration waves, validate them against known behaviour, and defer complex modernisation work until the workload is operating in a more flexible environment.

That does not make lift and shift effortless. A workload can be moved without code changes and still require careful work on identity, networking, firewall rules, DNS, certificates, backups, disaster recovery, monitoring, capacity, patching, and cutover planning. An application that depended on low-latency local systems or informal shared storage may behave differently once distributed across cloud networks.

The strategic limitation is that rehosting preserves many of the constraints that created the modernisation problem in the first place. A monolith remains a monolith. Manual releases remain manual. An over-provisioned server may become an over-provisioned cloud instance. Licensing, fragile batch jobs, and poor observability do not disappear because they now run in a cloud region.

AWS describes rehosting as a way to migrate with no application changes, while noting that the workload does not yet take advantage of cloud optimisation capabilities. That is why lift and shift should usually be treated as a deliberate first stage, accompanied by a funded post-migration plan rather than an endpoint.

Choose lift and shift when

• A hard deadline makes migration speed the central constraint.
• The application is stable, understood, and not a near-term product differentiator.
• Vendor constraints prevent major change.
• The organisation needs to remove data-centre, hardware, or resilience risk promptly.
• There is insufficient test coverage or internal capacity for safe application change before migration.
• You have an agreed follow-on phase for optimisation, security improvement, or retirement.

Watch for these failure modes

The most common mistake is declaring success at cutover. A team moves an estate quickly, but does not assign ownership or budget for right-sizing, backup validation, monitoring, resilience testing, or technical debt reduction. Cloud spend then rises because servers retain on-premises sizing assumptions and environments are left running indefinitely.

A second mistake is migrating technical dependencies without understanding business dependencies. A reporting system may appear non-critical until month-end; a legacy service may silently provide identity or data to several other applications. Discovery must go beyond server inventory.

For organisations managing a large estate, a disciplined cloud migration and modernisation programme should turn these dependencies into a wave plan, runbook, rollback approach, and measurable operational acceptance criteria.

Replatforming: change the parts that create friction

Replatforming sits between a pure move and a redesign. The application remains recognisable, but selected components are changed to improve how it operates in the cloud.

Typical examples include:

• Moving a self-managed database to Amazon RDS while retaining the database engine.
• Upgrading an unsupported operating system or runtime as part of the move.
• Containerising a web application without decomposing the application into microservices.
• Replacing a file-server dependency with managed object storage.
• Introducing infrastructure as code, centralised logging, managed backups, automated patching, or a standard CI/CD pipeline.
• Porting an application from Windows to Linux where the software and support model allow it.

This strategy is often the most practical choice for enterprise workloads. It addresses clear risks and operational costs without assuming that every application needs a complete rewrite. AWS explicitly uses moving SQL Server to Amazon RDS for SQL Server as a replatforming example, and notes that replatforming can reduce operational overhead through managed and serverless services. AWS’s replatforming guidance is useful for planning changes to ageing operating systems, databases, observability, validation, and patching.

The important phrase is “selected components.” Replatforming should be driven by a defined outcome: removing an end-of-support platform, reducing database administration, improving recoverability, eliminating costly licences, or making deployments repeatable. It should not become an unfocused list of attractive cloud services.

Consider an established customer portal running on virtual machines with a self-managed SQL Server database. A lift-and-shift approach may get the portal to cloud quickly, but retains operating system patching, database backups, failover design, and manual capacity work. A replatformed target might retain the portal application while moving the database to a managed service, adding automated deployments, centralised observability, and a more resilient compute tier. The result is still familiar to users and support teams, but easier to run and improve.

Choose replatforming when

• Supported versions, security exposure, licensing, or manual operations are the central problem.
• You need tangible cloud benefits within the migration programme.
• The application is valuable and likely to remain in service, but does not warrant a full redesign.
• There is enough test coverage, product knowledge, and delivery capacity to safely change selected components.
• A managed service can remove operational effort without compromising functional requirements.
• You can define a narrow, testable scope for the changes.

What replatforming requires

Replatforming needs more rigorous planning than lift and shift because the team is changing application assumptions. Database migrations may expose unsupported SQL features, performance behaviours, stored procedures, replication patterns, or tooling dependencies. A runtime upgrade may reveal hidden library and certificate dependencies. Containerisation can expose assumptions about local disk, sessions, configuration, and startup order.

Before committing to the target state, validate it with a representative workload and real operational scenarios:

• Does the application meet performance requirements under realistic load?
• Can you restore data within the required recovery objectives?
• Are privileged access, audit logs, encryption, and retention controls appropriate?
• Can the support team diagnose failures without direct server access?
• Is the vendor willing to support the application on the proposed platform?
• Is there a tested cutback path if production validation fails?

This is where cloud consultancy has practical value: architecture choices need to be joined to data movement, security controls, delivery ownership, and uptime constraints—not assessed as isolated technology selections.

Refactoring (re-architecting): redesign for a different operating model

Refactoring, sometimes called re-architecting, changes the application architecture so that it can make fuller use of cloud capabilities. That might involve splitting a tightly coupled monolith into independently deployable services, introducing event-driven processing, adopting containers or serverless functions, changing the data model, redesigning integration boundaries, or replacing synchronous processes with asynchronous workflows.

This is the strategy to choose when the existing application itself is the limiting factor. The business may need faster delivery of product changes, much greater scale, global availability, stronger resilience, or integration capabilities that the current architecture cannot safely provide. It can also be necessary when a workload’s operating system, runtime, framework, or database is no longer viable.

Refactoring can create major long-term value, but it is not a migration shortcut. It is product and organisational change carried out alongside infrastructure transformation. Teams need product ownership, domain knowledge, automated testing, security design, observability, deployment engineering, and clear decisions about data ownership and service boundaries.

AWS advises that refactoring is the most complex migration strategy and, for large migrations, generally recommends moving workloads through rehosting, relocating, or replatforming first where feasible, then modernising after migration. That is good advice when the objective is rapid estate migration. It does not mean refactoring should always wait. If a core product is already unable to meet customer or operational requirements, delaying architectural change may simply preserve a costly bottleneck.

Choose refactoring when

• The application architecture is directly preventing new product capabilities or reliable delivery.
• Scaling, resilience, latency, or integration requirements cannot be met through replatforming.
• The workload is strategically important enough to justify sustained investment.
• The team can protect production stability while changing the system.
• You have executive alignment on the business outcomes, not merely a desire to “be cloud native.”
• The work can be delivered incrementally, with measurable value along the way.

Avoid a big-bang rewrite

The familiar danger is replacing a working, if awkward, system with a multi-year rewrite that delivers no value until the end. The safer pattern is incremental modernisation: identify a bounded business capability, establish an integration seam, create the new service or workflow, migrate traffic or data gradually, and retire the old path once it is proven.

The strangler pattern is useful here, but only when the boundaries are genuine. Routing a few screens through a new front end while preserving one large, tightly coupled backend does not solve the underlying delivery problem. The technical design should follow the domain, data ownership, operational model, and team structure.

Refactoring also changes what “operations” means. Teams must be ready to own service-level objectives, incident response, distributed tracing, security patching, deployment automation, and cost accountability. Without that operational foundation, a cloud-native design can create more moving parts without improving outcomes.

The decision criteria that matter most

Cost should be part of the decision, but it should not be the first or only variable. A low-effort migration can be expensive to run; a more ambitious refactor can consume significant delivery budget before it produces return. Compare each strategy across five dimensions.

1. Business urgency

If a lease expiry, data-centre closure, security exposure, or merger deadline is fixed, lift and shift or targeted replatforming often provides the most credible path. If the urgency is market opportunity or a product constraint, refactoring may be justified.

2. Workload value and lifespan

Do not refactor a system that will be replaced, retired, or materially reduced within a year. Conversely, a revenue-critical platform likely to remain central for five years deserves more than a minimal relocation.

3. Technical health

Assess support status, test coverage, release frequency, dependency complexity, data sensitivity, architecture, and operational incident history. A fragile application with little knowledge may be safer to rehost first; a stable but operationally expensive application may be a strong replatforming candidate.

4. Delivery capability

The best target architecture on paper fails if the organisation cannot build and operate it. Refactoring requires mature engineering practices. Replatforming requires platform and test capability. Even lift and shift requires accountable owners for security, patching, backups, and cost management.

5. The cost of delay

Some costs do not appear in a cloud bill: delayed product releases, audit risk, prolonged manual work, unreliable customer experience, and an inability to integrate with partners. A decision model should make these visible alongside migration and run costs.

A practical way to choose

For each application, write a short decision record before choosing the migration strategy:

1. State the business outcome and deadline.
2. Identify the application owner, users, data classification, and upstream and downstream dependencies.
3. Estimate the migration effort, the annual operating cost, and the cost of postponing change.
4. Describe the minimum viable target architecture, including security, backup, monitoring, and support ownership.
5. Select the strategy and explain why the other two are not appropriate now.
6. Define success measures: cutover impact, recovery objectives, performance, release frequency, operating effort, or cost.
7. Specify the next decision point, particularly if lift and shift is only the first stage.

This prevents a migration strategy from becoming a label applied during planning and forgotten during delivery.

A mixed approach is often strongest. An organisation might rehost stable, low-change applications to meet a data-centre exit; replatform databases and high-maintenance operational systems; and refactor a customer-facing platform where delivery speed is a competitive concern. The architecture must still consider the interfaces between them, particularly identity, networking, data, integration, and observability.

Westpoint's Toyota cloud migration case study illustrates the importance of this balance: the work paired a cloud migration with a non-invasive identity layer, protecting existing systems while creating a foundation for future scale and control. That is often the real aim—not change for its own sake, but a safer route from legacy constraints to a platform the business can operate and evolve.

Choose the strategy that preserves options

Lift and shift is the right choice when speed and risk reduction matter most. Replatforming is the right choice when targeted changes can materially improve security, cost, resilience, or operations. Refactoring is the right choice when the existing architecture prevents the business from moving forward.

The strongest migration strategies do not force every workload into the same answer. They establish a clear target state, make trade-offs explicit, deliver in manageable waves, and ensure that the operating model is ready before production cutover.

If the goal is simply to move, lift and shift may be enough. If the goal is to run better, replatform. If the goal is to compete differently, refactor—carefully, incrementally, and with the delivery capability to sustain the change.