Lift-and-Shift vs Refactor

The question behind the question

When a team debates lift-and-shift against refactoring, it is rarely arguing about technology. It is arguing about when the benefits arrive and who absorbs the risk.

Lift-and-shift moves the workload as it is. Same operating system, same application, same architecture, different hardware underneath. The migration finishes sooner, the cloud bill often looks disappointing, and the improvements come later or not at all.

Refactoring rebuilds parts of the system to use the destination properly: managed databases instead of self-installed ones, object storage instead of a shared file mount, a container platform instead of hand-built servers. The benefits are larger and they arrive after a longer, riskier project.

Most real migrations use both, workload by workload. The skill is deciding which treatment each one gets, and this article is about making that decision defensible.

More than two options

The industry shorthand lists several migration treatments, and knowing the full set stops the debate collapsing into a false binary.

Retire deserves particular attention. Every discovery exercise turns up systems with no users, and deleting them is the cheapest migration available.

What each approach really costs

Rehosting is cheap in engineering time and expensive in operating cost. You inherit the sizing decisions made for physical hardware, which were usually generous, and you pay cloud rates for that generosity every hour. Idle capacity that was free when you owned the box becomes a line on the invoice.

It also carries a hidden cost that arrives later. A rehosted estate looks migrated on the project plan while remaining exactly as difficult to operate as before, and the promised second phase of improvements competes with feature work it usually loses.

Refactoring is expensive in engineering time and, done well, cheaper to run and far cheaper to operate. The risk is concentration: you are changing the platform and the application simultaneously, so when something breaks the cause is ambiguous.

Replatforming is the underrated middle. Moving a self-managed database to a managed one, or a file share to object storage, delivers most of the operational benefit without touching application logic. For many teams it is the highest return per unit of risk in the whole migration.

A decision matrix per workload

Score each workload against five questions and the treatment usually announces itself.

1. Is the code still actively developed, or is it frozen? Frozen code is a poor refactoring candidate because nobody will maintain the changes.
2. Does anyone still understand it? A system whose original authors have left should be rehosted first and studied afterwards.
3. Is there a specific pain the platform would fix? Scaling limits, fragile deployments and manual failover are concrete reasons; "modernisation" is not.
4. What is the deadline? A data centre contract ending in three months rules out refactoring, whatever the architecture review concluded.
5. How much would it cost to run as it is? A workload with large idle capacity rewards right-sizing more than rearchitecting.

A useful default emerges from these. Rehost what you must, replatform what you can, refactor only what is both actively developed and demonstrably painful.

Score the workloads in one session with the people who operate them, and record the reasoning next to each answer rather than only the verdict. Six months later, when someone asks why the reporting system was rehosted, the note is what stops the debate reopening.

Expect a handful of workloads to resist classification. Those are usually the ones with an undocumented dependency or an unclear owner, and the right response is to investigate them rather than to assign a treatment and hope.

Shift first, improve second

The sequence that works for most teams is to move with minimal change, stabilise, then improve deliberately with the workload already in its new home.

This works because it separates two sources of failure. If you move and rearchitect at once, an incident could be caused by the new platform or the new code, and you will spend the outage arguing about which. Move first and the variable is isolated.

It only works if the improvement phase is actually funded. Write the intended replatforming work into the project plan with dates and owners, not as an aspiration in the closing slide. A migration that ends the moment the last server boots leaves the organisation with cloud costs and data centre habits.

The wider sequencing of a migration into waves, and how these treatments fit inside it, is covered in cloud migration planning.

Signals that point each way

Refactor when the application already struggles with the load it has, when deployments are risky enough that people avoid them, when state is trapped on individual servers, or when a managed service would remove an entire category of work. Container platforms and managed orchestration pay off here, and the threshold for that particular choice is discussed in managed Kubernetes for small teams.

Rehost when the clock rules, when the system is stable and boring, when licensing makes rebuilding expensive, or when the workload is scheduled for replacement anyway. There is no virtue in rearchitecting something you intend to retire next year.

Be wary of two failure modes. The first is refactoring by accident, where a rehost gradually accumulates changes until it is neither a clean move nor a deliberate rebuild. The second is adopting proprietary services during a refactor without noticing how much they bind you, a trade examined in cloud vendor lock-in.

Key takeaways

• Treat this as a per-workload decision, not a programme-wide doctrine.
• Remember the wider set of treatments, and retire everything nobody uses before moving it.
• Rehosting trades operating cost for speed; refactoring trades time and risk for a better resting state.
• Replatforming often delivers the best return per unit of risk, because it improves operations without touching application logic.
• Move first and improve second, but fund the improvement phase explicitly or it will not happen.
• Right-size early, since hardware-era sizing is the most common source of disappointing cloud bills.

For platform-specific tooling, AWS documents its rehosting service in the Application Migration Service guide, and Microsoft describes the equivalent assessment and migration flow in the Azure Migrate documentation. Where the destination is still open, the AWS and Azure comparison covers how each platform receives an incoming estate, and the AWS account listings describe what that side provides.