Lift and shift is a migration approach that moves an application into the cloud with minimal redesign. It can accelerate migration, but it often preserves the original architecture’s inefficiencies. In cloud environments, that can lead to oversizing, redundant services, and higher recurring costs than a cloud-native redesign would create.
What Lift And Shift Really Means in Cloud Migration
Lift and shift is best understood as a speed-first migration pattern, not a redesign strategy. The core trade-off is that you move runtime location and operating responsibility into the cloud while leaving architecture, dependencies, and operational assumptions largely intact.
That makes the approach attractive when timelines are tight, but it also means the cloud often inherits the same coupling, state management, and scaling constraints that existed on premises. In practice, the migration changes where the system runs before it changes how efficiently it runs.
A lift-and-shift move is therefore still a cloud decision, but it is not automatically a cloud-optimisation decision. Teams often use it to retire infrastructure quickly, then accept that the application may need a second phase of refactoring to realise the full benefits of the target environment.
Where Lift And Shift Fits in Migration Strategy
Lift and shift sits at the low-transformation end of the migration spectrum. It is usually chosen when the primary goal is to exit a data centre, meet a deadline, reduce operational overhead, or preserve a working system while broader modernisation work happens later.
The approach is most defensible when the application is stable, business-critical, and difficult to redesign safely under time pressure. It is also common for legacy workloads whose value lies in continuity rather than architectural elegance.
Because the application is minimally changed, the migration team is often preserving not just code, but also database shape, deployment patterns, batch jobs, network assumptions, and tooling. That is why the outcome can look successful on day one while still carrying the technical debt of the original environment.
What Lift And Shift Preserves, and What It Changes
The defining feature of lift and shift is that it changes the hosting environment more than the application itself. Compute, storage, and network placement move into cloud infrastructure, but the application may still rely on the same monolith boundaries, shared services, and fixed capacity assumptions.
That preservation has operational value because it reduces migration complexity and shortens cutover. It also means performance bottlenecks, license constraints, and inefficient resource sizing can survive the move unless someone deliberately revisits them.
For many teams, the real question is whether the cloud migration is intended to be final or transitional. If the answer is transitional, lift and shift can be a sensible first step, especially when paired with later right-sizing, resilience work, or decomposition.
For readers comparing migration patterns, NHIMG’s Ultimate Guide to Non-Human Identities is useful for understanding how modern cloud estates accumulate operational dependency and control complexity around machine-accessed services, credentials, and automation.
Security and Cost Implications of Lift And Shift
Lift and shift can increase recurring cost when cloud spend mirrors the inefficiency of the source environment. Oversized instances, duplicated services, and underused capacity are common when a legacy footprint is replicated without re-evaluating utilisation patterns.
From a security perspective, the bigger issue is often that old assumptions survive the move. If the source system had weak segmentation, broad administrative access, fragile secrets handling, or limited observability, those problems can be transplanted into the cloud with the workload.
The cloud may improve availability and deployment flexibility, but only if the architecture is adapted to the new operating model. If not, teams can end up with more cost, more complexity, and the same control weaknesses in a new place.
Cloud migration programs also need to account for the identity and access layer around migrated services. NHIMG’s Ultimate Guide to Non-Human Identities shows why machine credentials, service accounts, and automation paths matter when applications move without redesign.
Risk and Threat Considerations
Lift and shift can preserve legacy exposure as well as legacy functionality. When an application is moved quickly, the organisation may inherit the same privilege sprawl, weak segmentation, stale secrets, and monitoring gaps that already existed, only now they sit inside a cloud trust boundary.
Failure mechanism: The migration copies an old operating model into a new environment without resetting access, network, or configuration assumptions, so attackers, misconfigurations, or operational mistakes can exploit the preserved weakness at cloud scale.
Impact: The result can be higher blast radius, persistent overprovisioning, unnecessary exposure of services, and a false sense of modernization that delays real remediation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV — Govern | Lift and shift is a migration governance decision with cost and risk trade-offs. |
| PR.DS — Data Security | Copied workloads can carry legacy secrets and data-handling weaknesses into the cloud. | |
| Recommendation — Define migration decision criteria and accountability for when relocation should be followed by redesign. Protect migrated data and secrets by revalidating handling, storage, and access assumptions after cutover. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Lift and shift often moves existing assets unchanged, so accurate inventory is central to migration control. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Lift and shift preserves configuration debt unless cloud settings are rebaselined. | |
| CIS-12 — Network Infrastructure Management | Migrated applications often keep old network assumptions that affect exposure and segmentation. | |
| Recommendation — Inventory migrated assets and remove duplicate or obsolete systems after relocation. Rebaseline cloud configurations after migration instead of carrying forward legacy defaults. Reassess network boundaries and segmentation for each lifted workload. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl and Exposure | Lifted applications can carry forward secrets in code, configs, and CI/CD paths. |
| NHI-03 — Excessive Permissions and Privilege Creep | Cloud rehosting can preserve overprivileged service accounts and automation access. | |
| Recommendation — Eliminate inherited secret sprawl before and after workload migration. Reevaluate machine and service privileges when workloads move into cloud infrastructure. | ||
Practitioner Guidance
Why practitioners should care: Lift and shift is often valuable as a delivery tactic, but it should be treated as the start of a migration journey, not the end state. If the business stops at relocation, the cloud bill and the security posture can both reflect the source system’s inefficiencies.
Common misunderstanding: Faster migration does not mean improved architecture. A successful cutover can still leave the organisation with an expensive, hard-to-secure workload that needs a follow-on optimisation plan.
Practitioner takeaway: Use lift and shift when speed matters, then explicitly schedule the redesign, rightsizing, and control hardening needed to make the cloud environment materially better than the one you left.
Related resources from NHI Mgmt Group
- What do teams get wrong when they lift and shift identity systems to the cloud?
- Why do lift-and-shift migrations create hidden identity and compliance risk?
- What breaks when lift-and-shift migrations leave governance behind?
- What breaks when a QRadar migration treats SIEM replacement as a lift-and-shift?
