This chapter covers lift-and-shift versus refactor migration approaches, the two ends of a common migration spectrum. AZ-900 tests this under objective 1.1, building on the migration overview from the previous chapter.
Jump to a section
A simple way to picture Lift-and-Shift vs Refactor Migration
When moving to a new house, you could bring your existing furniture exactly as it is, even if it doesn't perfectly fit the new layout — quick and simple, but not optimized for the new space. Or you could redesign and replace furniture specifically to fit the new house better — more effort, but a better long-term fit. Lift-and-shift migration is like moving furniture as-is: applications are moved to the cloud largely unchanged. Refactoring is like redesigning for the new space: applications are modified to take fuller advantage of cloud-native capabilities.
Lift-and-shift (rehosting)
Lift-and-shift, also called rehosting, means moving an application to the cloud largely as-is, with minimal changes to its architecture. It's generally faster and lower-risk to execute, but doesn't take full advantage of cloud-native capabilities like autoscaling or managed services, since the application's underlying design remains essentially unchanged.
Refactoring
Refactoring means modifying an application, to a greater or lesser degree, to better take advantage of cloud-native capabilities — for example, moving from a self-managed database on a VM to a managed database service, or redesigning parts of the application to use serverless components. This generally takes more time and effort than lift-and-shift, but can result in a more cost-efficient, scalable end state.
Choosing between them
There's no universally "correct" choice — lift-and-shift suits situations where speed and lower risk matter most, or where an application isn't expected to benefit significantly from deeper cloud-native redesign. Refactoring suits situations where the additional investment is justified by longer-term efficiency or scalability gains.
A migration project may use both
A single migration effort often uses lift-and-shift for some applications and refactoring for others, based on each application's specific characteristics and business priority, rather than committing to one approach uniformly across everything.
Assess whether the application needs redesign
Consider whether the application would meaningfully benefit from cloud-native redesign, or whether moving it largely as-is is sufficient for its needs.
Choose lift-and-shift for speed and lower risk
If moving quickly with minimal disruption is the priority, lift-and-shift generally offers a faster, lower-risk path to the cloud.
Choose refactoring for longer-term efficiency
If the application would significantly benefit from cloud-native capabilities, and the additional investment is justified, refactoring can lead to a more efficient, scalable end state.
Mix approaches across a broader migration effort
A migration project often applies different approaches to different applications, rather than choosing one method for everything.
An organization migrates a legacy application it plans to retire in the near future using lift-and-shift, since investing heavily in refactoring an application with a limited remaining lifespan wouldn't be worthwhile.
The same organization refactors a core, long-term business application during its migration, redesigning it to use managed cloud services instead of the self-managed infrastructure it previously relied on — accepting the additional upfront effort in exchange for better long-term efficiency and scalability for an application expected to remain important for years.
Objective 1.1 expects candidates to distinguish lift-and-shift (rehosting largely as-is) from refactoring (modifying to better use cloud-native capabilities), and to understand that the right choice depends on the specific application and situation.
A common wrong answer is assuming refactoring is always the "better" choice — it requires more time and effort, and isn't automatically justified for every application, especially ones nearing retirement or with limited expected lifespan.
Stable terms: lift-and-shift, rehosting, refactoring. Memory trick: lift-and-shift = move as-is, quickly. Refactor = redesign to better fit the cloud, taking more effort for potentially better long-term results.
Lift-and-shift (rehosting) moves an application to the cloud largely unchanged, prioritizing speed and lower risk.
Refactoring modifies an application to better use cloud-native capabilities, taking more effort for potentially better long-term results.
The right approach depends on the specific application's needs, expected lifespan, and business priority.
A single migration project often uses both approaches across different applications.
These come up on the exam all the time. Here's how to tell them apart.
Lift-and-Shift
Moves the application largely as-is
Generally faster and lower-risk
Doesn't fully leverage cloud-native capabilities
Refactoring
Modifies the application for cloud-native fit
Generally takes more time and effort
Can result in better long-term efficiency and scalability
Mistake
Refactoring is always the better migration approach.
Correct
It requires more time and effort than lift-and-shift, and isn't automatically justified for every application — the right choice depends on the specific application's expected lifespan and potential benefit from redesign.
Mistake
A migration project must use only one approach for every application.
Correct
A single migration effort often mixes lift-and-shift and refactoring across different applications, based on each one's specific characteristics and priority.
Lift-and-shift (rehosting) moves an application to the cloud largely as-is, with minimal changes — faster and lower-risk, but not fully taking advantage of cloud-native capabilities. Refactoring modifies the application to better use those capabilities, requiring more effort but potentially yielding better long-term efficiency.
It depends on the specific application — lift-and-shift suits situations prioritizing speed and lower risk, or applications with limited expected lifespan. Refactoring suits applications where the additional investment is justified by longer-term efficiency or scalability gains.
You've just covered Lift-and-Shift vs Refactor Migration — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?