Lift and shift vs refactor is a choice about what needs to change. Lift and shift, which AWS calls rehosting, moves a system to new infrastructure without changing the application. Refactoring changes the code, and often the architecture, so the system is easier to change afterwards. The first fixes where it runs; the second fixes how it's built.
We covered the full menu, from retaining a system to retiring it, in legacy system modernization. This post is narrower: how the approaches compare, using AWS's own definitions, and the questions that should settle the choice.
- Lift and shift, which AWS calls rehost, moves a system to new infrastructure with no changes to the application. Refactoring changes the code, and in AWS's usage, the architecture.
- AWS Prescriptive Guidance lists seven migration strategies, the 7 Rs. Rehost, replatform and refactor are the three most often compared.
- Lift and shift moves the debt with the system. Slow releases, untested code and tangled modules arrive on the new hosting unchanged.
- Decide on three questions: why you're moving at all, what's wrong with the code today, and how much of the system anyone understands.
What is the lift and shift approach?
Lift and shift means moving an application to new hosting exactly as it is. AWS Prescriptive Guidance calls it rehost: "you move your applications from your source environment to the AWS Cloud without making any changes to the application." The code, database design, batch jobs and release process stay the same. Only the servers underneath change.
What are the 7 Rs of migration in AWS?
The same guide lists seven strategies, "known as the 7 Rs": retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. AWS calls selecting among them "critical to a large migration."
The list has grown. AWS's 2016 post 6 Strategies for Migrating Applications to the Cloud, by Stephen Orban, named six and said they "build upon the 5 R's that Gartner outlined here in 2011." Compare the two AWS lists and the addition is relocate.
Rehost vs refactor vs replatform: what's the difference?
The difference is how much of the application changes. Rehost changes nothing in it, replatform changes some of it, and refactor changes its design.
AWS describes replatform, also called "lift, tinker, and shift," as moving to the cloud while you "introduce some level of optimization." Its example is moving a Microsoft SQL Server database to Amazon RDS for SQL Server. AWS adds that you "might make a few or many changes to the application," which is worth reading twice when someone calls a replatform small.
Refactor, in AWS's list, means you "modify its architecture by taking full advantage of cloud-native features." AWS calls refactoring "the most complex and costly of the migration strategies."
The word refactor means two things
Outside migration planning, refactoring has a narrower meaning. Martin Fowler, on refactoring.com, defines it as "a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior." That kind needs no cloud move and can be done on premises, one module at a time. When a vendor proposes refactoring, ask which kind they mean. Our post on refactoring legacy code covers the second.
Lift and shift vs refactor vs replatform, side by side
| Approach | What changes | Effort | When it fits | Main risk |
|---|---|---|---|---|
| Retire | The application is decommissioned or archived | Small, once you know who uses it | Nobody needs it, or another system does the job | A report someone relies on disappears |
| Retain | Nothing, for now | None yet | It needs assessment first, or depends on another move | "For now" becomes permanent |
| Rehost (lift and shift) | Hosting only, no changes to the application | Low | Hardware or a data center exit is the problem | Every problem in the code moves with it |
| Relocate | Servers move to a cloud version of the same platform | Low | You want the same platform, run in the cloud | Nothing about the application improves |
| Repurchase | A different version or product, often SaaS, replaces it | Medium, mostly data and integration | The function is common and a product does it | Custom rules the product won't handle |
| Replatform | Some optimization on the way, such as a managed database | Medium | A support date or running cost forces a move | A few changes become many |
| Refactor or re-architect | The architecture, to use cloud-native features | High | The design blocks what the business needs | Stalling halfway, or losing rules nobody wrote down |
The "What changes" column follows AWS Prescriptive Guidance, checked 27 October 2026. Effort and risk are our judgment.
Why lift and shift moves the debt with the system
A lift and shift changes a system's address, not its contents. Whatever made it hard to change before the move still does after: the rule coded in three places, the tests nobody trusts, the manual release steps. They're the technical debt examples most teams know, now on new hosting.
AWS's guide is candid about the trade. For large migrations it advises against refactoring during the move, and recommends "rehosting, relocating, or replatforming the application and then modernizing the application after the migration is complete." That's sound advice for a data center exit, but it depends on the second step happening. If the modernization budget goes to the next project, the debt stays.
So our rule is to choose on what's inside the code, not on what the hosting needs. If the code is sound, lift and shift is often right. If the code is the problem, moving it only changes where the problem runs.
Three questions that decide it
1. Why are you moving at all?
Write the reason down in one sentence.
- Hardware is failing, or the data center contract is ending. Rehost or relocate to meet the date. The code isn't the issue.
- A license or support date is forcing a change. Replatform, if moving to a supported database or runtime is the whole job. Check the date on the vendor's own lifecycle page.
- Every change takes too long. No hosting move fixes that. It's a refactoring problem, before, after or without a migration.
2. What's wrong with the code today?
Ask the team where changes are slow and why. If the answer is the servers, the code can travel as it is. If it's the code, list what's in the way: modules that reach into each other's tables, rules duplicated across screens and batch jobs, tests nobody trusts. Our code audit checklist covers where to look. Every item travels with the system in a lift and shift, and every item is scope in a refactor.
3. How much of the system does anyone understand?
This decides whether refactoring is possible yet. AWS lists "a legacy application that nobody knows how to maintain" as a use case for refactoring. That's a fair reason the system needs work, and also why the work can't be planned yet: nobody can redesign what nobody can describe. Fowler's definition depends on behavior not changing, and you can only show that if you know what the behavior is. If the rules live in stored procedures, overnight jobs and one developer's memory, read the code first, as we explain in before you rewrite a legacy system.
Before you choose an R: the 30-day assessment
All three questions need the same evidence: what the code does, and what state it's in. The 30-day assessment provides that for one system. It's fixed in scope, at a price agreed before we start. Over 30 days we read the codebase and the architecture around it, map how the system fits together and what it depends on, find the hidden architectural debt, and flag the security and compliance gaps.
The report says in plain language what is broken and what it would take to fix it, which shows whether the code can travel as it is. Your own team can act on it, whichever R you choose, or we can do the work as a separate project with its own scope and price. The report stands on its own.
Pick a time to talk about the system you're planning to move. If a narrower check would answer the question, we'll say so.