Lift and Shift Migration Done Right the First Time
Lift and shift migration, also called rehosting, moves applications from on-premises servers to the cloud with no code changes. It is the fastest path to cloud infrastructure and works best for stable, compatible workloads where speed matters more than architectural optimization. Most teams choose it when a data center lease is expiring, a hardware refresh is due, or a broader modernization program needs a low-risk first phase to build momentum.
This guide walks through every execution phase in order, from workload assessment to post-migration right-sizing, and flags the decision points where rehosting succeeds or stalls. Success means the workload runs stably in the cloud, cost reductions are measurable within four months, and no dependencies were missed before cutover.
What Is Lift and Shift Migration?
Lift and shift migration takes an existing application, its operating system, dependencies, and configuration, and moves the entire stack to cloud infrastructure without modifying the code. The application runs in the cloud the same way it ran on-premises. Nothing is rewritten, refactored, or re-architected.
The core mechanism is server replication. Migration tooling captures the current state of the on-premises machine, transfers that image to a cloud instance, and brings the workload online in the target environment. The process preserves the application's behavior, which is both its main advantage and its main constraint.
Adoption data confirms this is a mainstream strategy, not a niche workaround. According to research published in the Eastern-European Journal of Enterprise Technologies, lift and shift strategies appeared in 39.64% of successful cloud migration cases. A separate 2026 SkilBrill benchmark study found rehosting to be the second most common migration strategy, used by approximately 32% of surveyed enterprises. The two studies use different samples and methodologies, so the figures differ, but both place rehosting among the top two strategies enterprises actually execute. For a broader overview of how these strategies fit into a full program, see the cloud migration services guide.
The approach suits workloads that are stable and well-understood: line-of-business applications with predictable load, internal tools that run on supported operating systems, and databases that have no hard dependencies on physical hardware. It is less suited to applications that rely on bare-metal performance, software with cloud-incompatible licensing, or systems so tightly coupled to on-premises infrastructure that replication alone cannot reproduce their behavior.
Rehosting is also a common first phase in a longer modernization program. A team moves a workload to the cloud intact, then optimizes or refactors it once it is running on cloud-native infrastructure. That sequencing reduces risk: the application is available in the cloud before any architectural work begins.
How Does Lift and Shift Compare to Replatforming and Refactoring?
Three migration strategies cover most enterprise workloads: rehosting, replatforming, and refactoring. Each requires a different level of effort and delivers a different outcome. Choosing the wrong one for a given workload is one of the most common reasons migrations run over budget or fail to deliver expected value.
Rehosting moves the application as-is. No code changes, no dependency modifications. The workload runs on a cloud VM that mirrors the on-premises server. Speed is the primary advantage.
Replatforming makes targeted adjustments without rewriting the application. A team might swap a self-managed database for a managed cloud database service, or move from a self-hosted application server to a managed container platform. The application logic stays intact; the infrastructure layer changes. This adds time and some risk, but the workload gains operational benefits like automated patching and built-in scaling.
Refactoring rebuilds the application to use cloud-native services and architecture patterns. APIs replace direct database calls. Monolithic services split into independently deployable components. This delivers the most long-term value but requires the most time, skill, and budget. It is the right choice for applications where the current architecture is the bottleneck.
Strategy | Code Changes Required | Speed to Cloud | Best For |
Rehosting (Lift and Shift) | None | Fastest | Stable workloads, deadline-driven migrations, first-phase moves |
Replatforming | Minimal to moderate | Moderate | Applications that need managed services without a full rewrite |
Refactoring | Significant | Slowest | Applications where architecture limits performance or scalability |
The right choice depends on the workload's age, architecture, and the team's tolerance for disruption. A 10-year-old ERP system with a vendor support contract is a rehosting candidate. A custom-built application that struggles to scale under peak load is a refactoring candidate. Most enterprise estates contain workloads in all three categories, which is why migration programs typically run all three strategies in parallel across different application groups.
What Are the Real Benefits of Rehosting, and Where Does It Fall Short?
Rehosting has three concrete advantages: speed, cost reduction, and low operational disruption. It also has real limitations that teams underestimate when they plan only for the migration and not for what comes after.
On cost, the data is specific. The Eastern-European Journal of Enterprise Technologies found that the average lift and shift migration results in a cost reduction of 40.06%. That figure reflects the shift from fixed capital expenditure on physical servers to variable cloud consumption, combined with reduced data center overhead. The SkilBrill benchmark study puts the median time to achieve measurable cost reduction at 4 months after a rehost migration. For a mid-market team under pressure to show ROI, that timeline is meaningful.
Speed is the other headline benefit. Because no code changes are required, a rehost migration can move faster than any other strategy. Teams that need to exit a data center before a lease expires, or that need to free up capital tied up in aging hardware, can execute a rehost in weeks rather than quarters.
The limitations are equally concrete. Rehosting moves the application but does not improve it. An application that was over-provisioned on-premises will be over-provisioned in the cloud unless the team right-sizes instances after migration. An application with a monolithic architecture will still have that architecture after the move. Performance bottlenecks tied to code do not disappear because the workload now runs on cloud infrastructure.
Over-provisioning is a common and expensive outcome. Teams that replicate on-premises server sizes directly into cloud instances often pay for compute capacity they do not use. Right-sizing after migration is not optional; it is the step that closes the gap between the theoretical cost reduction and the actual bill.
Budget risk is also real, though it applies to IT transformation broadly. A study by Natuvion and NTT Data found that 82 percent of companies exceed their budget during IT transformation projects. That figure covers IT transformation generally, not rehosting specifically, but the underlying causes, poor scoping, undetected dependencies, and inadequate testing, apply to any migration.
How to Execute a Lift and Shift Migration: Step-by-Step
Execution is where most rehosting projects succeed or fail. The steps below follow the order a team actually works through them, from initial assessment to traffic cutover. Skipping or compressing any phase is the most common cause of post-migration instability.
The word "successful" matters in the Eastern-European Journal of Enterprise Technologies finding that lift and shift appeared in 39.64% of successful cloud migration cases. The teams behind those numbers completed each phase in sequence rather than rushing to cutover.
Identify viable migration candidates. Evaluate each application for cloud compatibility, performance requirements, and licensing constraints [S1]. An application that relies on a license tied to physical hardware, or that requires bare-metal I/O performance, is not a rehosting candidate. Document dependencies between applications at this stage. A workload that looks standalone often has undiscovered connections to shared databases, file shares, or authentication services. Missing a dependency here creates outages after cutover.
Begin server replication. Once candidates are confirmed, start replicating the application's current state from on-premises infrastructure to the target cloud environment [S2]. Replication runs continuously in the background, keeping the cloud copy in sync with the source. This phase does not interrupt production. Teams use this window to validate that the cloud instance boots correctly, that network paths are open, and that monitoring is in place before any traffic moves.
Docker is useful here. It replicates existing software configurations and environments so teams can test application behavior in the cloud before the production migration runs. Running the application in a containerized environment that mirrors the on-premises stack surfaces configuration mismatches early, when they are cheap to fix.
Freeze data ingestion in the source environment. Before the final move, stop all new transactions in the source system [S3]. This is the step teams most often try to shorten. Any transaction that completes after replication ends but before the final sync creates a data gap. The freeze window should be as short as possible, but it cannot be zero. Communicate the maintenance window to affected users in advance.
Perform the final data synchronization. With the source frozen, run a final sync to bring the cloud target fully up to date [S4]. Verify record counts, checksums, or application-specific consistency checks before proceeding. Do not move to the next step until the data in the cloud environment matches the source exactly.
Redirect user traffic to the cloud environment. Update DNS records or load balancer targets to send traffic to the cloud instance [S5]. Keep the on-premises environment running but offline from production traffic for a defined rollback window, typically 24 to 72 hours. If a critical issue surfaces after cutover, the rollback path is to repoint traffic back to the source. After the rollback window closes without incident, decommission the source.
Conduct validation testing and right-size resources. Run functional tests, performance checks, and integration verification against the live cloud environment [S6]. Compare response times and error rates against pre-migration baselines. Identify instances that are over-provisioned relative to actual workload and resize them. This step is covered in detail in the checklist below.
Post-Migration Validation and Right-Sizing Checklist
The migration cutover is not the finish line. The work that happens in the first four weeks after cutover determines whether the cost reductions and performance targets are actually achieved. Teams that skip post-migration optimization push the path to measurable savings out further, or miss it entirely.
Work through the following after traffic has moved to the cloud:
Functional validation. Test every critical user workflow end to end. Confirm that integrations with external systems, authentication services, and downstream applications are operating correctly. Do not rely on the absence of error reports as a proxy for success.
Performance baseline comparison. Measure response times, throughput, and error rates against the baselines captured before migration. Flag any metric that has degraded noticeably for investigation before closing the project.
Log and monitoring verification. Confirm that application logs, infrastructure metrics, and alerting rules are flowing to the monitoring platform. A workload that migrated without its observability configuration is invisible when problems occur.
Backup and recovery testing. Verify that backup jobs are running on schedule in the cloud environment and that at least one restore test has been completed successfully. Do not assume that backup configuration transferred with the workload.
License and compliance audit. Confirm that software licenses are valid in the cloud environment. Some licenses are tied to physical hardware or specific geographic regions. Identify any that need to be renegotiated or replaced.
Instance right-sizing. Pull CPU, memory, and storage utilization data for the first two to four weeks of cloud operation. Resize instances where utilization data shows consistent over-provisioning relative to actual workload. Over-provisioned instances are the primary source of unnecessary spend after a rehost migration.
Cost anomaly review. Set budget alerts and review the first billing cycle against projections. Unexpected charges most often come from data egress, unattached storage volumes, or instances left running in test environments.
Migration Tool Landscape: What to Know Beyond Native Cloud Services
Native cloud migration services from the major providers handle the core replication and cutover workflow for most workloads. They cover agent-based and agentless discovery, continuous replication, and cutover orchestration. For straightforward rehosting projects, these services are often sufficient.
Where teams run into gaps is environment consistency. A workload that replicates cleanly at the infrastructure level can still behave differently in the cloud if the runtime environment, library versions, environment variables, or configuration files differ from the source. Native migration services move the machine; they do not always guarantee that the application's software environment is reproduced exactly.
Docker addresses that gap. It captures the application's existing software configuration and dependencies into a portable container image, which can be tested in the cloud environment before the production migration runs. Per excella.com, Docker is used as a transitional step or a means to ensure environment consistency during migration. Running the containerized version of the application in the cloud before cutover surfaces mismatches between the on-premises and cloud environments while there is still time to correct them without affecting production.
The right tool combination depends on the workload type, the target cloud provider, and whether the team is moving a handful of servers or a large application estate.
According to the Voice of Kubernetes Report 2026, 34% of organizations plan to migrate on-premises VMware workloads to the public cloud using a lift and shift approach. For teams in that group, containerization tooling is particularly relevant: VMware workloads often have configuration dependencies that are easier to capture and validate in a container image than to reproduce manually in a cloud VM. Tooling decisions that shorten the validation phase directly affect how quickly the financial case closes.
For teams evaluating how migration tooling fits into a managed engagement, the managed cloud migration engagement guide for mid-market enterprises covers what a structured program includes from assessment through steady-state operations. Teams looking for a starting point can also review the cloud migration services overview for context on how engagements are structured.
When Should You Bring in a Cloud Migration Partner?
Most mid-market IT teams can handle a small rehosting project with internal resources. Three or four servers, well-understood applications, and a clear target environment are manageable. The calculus changes when the scope grows, the timeline compresses, or the workload mix includes applications with undocumented dependencies.
The signals that a project exceeds in-house capacity are specific. A migration involving 50 or more servers across multiple application groups requires dependency mapping at a scale that takes weeks to do correctly. A hard deadline, a data center lease expiring in 90 days, for example, leaves no room to discover a missed dependency after cutover. And budget risk is real: a study by Natuvion and NTT Data found that 82 percent of companies exceed their budget during IT transformation projects. Poor scoping and undetected dependencies are the two most common causes, both of which a partner with migration experience is positioned to catch early.
The right partner brings three things that are hard to replicate internally on a compressed timeline: a repeatable assessment methodology that surfaces dependencies before replication starts, hands-on experience with the tooling, and accountability for the outcome rather than just the advice.
That combination is hard to replicate internally on a compressed timeline.
For teams weighing whether to run a migration internally or with outside support, the 5 critical factors for a successful AWS migration covers the planning decisions that most often determine whether a project finishes on time and on budget.
FAQs
What is the most common enterprise cloud migration strategy?
Rehosting and replatforming consistently rank as the top two strategies enterprises actually execute. According to the 2026 SkilBrill benchmark study, rehosting is the second most common strategy, used by approximately 32% of surveyed enterprises. Research published in the Eastern-European Journal of Enterprise Technologies places lift and shift usage at 39.64% of successful migration cases. Both studies use different samples, but each places rehosting among the strategies most commonly completed, not just planned.
What is the Azure Migrate tool?
Azure Migrate is Microsoft's native service for discovering, assessing, and replicating on-premises workloads to Azure. It handles agentless and agent-based discovery, dependency mapping, and continuous replication for server migrations. It also includes cost estimation tools that model Azure spend against on-premises sizing before the migration runs. For straightforward rehosting projects targeting Azure, it covers the core workflow without requiring third-party tooling.
What are the common cloud migration strategies?
Most enterprise migration programs use some combination of rehosting, replatforming, and refactoring. Rehosting moves workloads as-is with no code changes. Replatforming makes targeted infrastructure adjustments without rewriting application logic. Refactoring rebuilds the application to use cloud-native architecture. Some programs also include a track for decommissioning applications that are no longer needed, or deferring workloads that are not yet ready to move.
How long does a typical lift and shift migration take?
Timeline depends on the number of workloads, the complexity of dependencies, and how much pre-migration assessment work has been completed. The SkilBrill benchmark study found that the median time to measurable cost reduction after a rehost migration is 4 months. That figure covers the period from migration through initial optimization, not just the cutover event itself. Simple, well-documented workloads can complete cutover in days; large, multi-application estates with undocumented dependencies take considerably longer. Teams that complete thorough dependency mapping before replication starts consistently land closer to the shorter end of that range.
What workloads are not suitable for lift and shift?
Four categories consistently cause problems in rehosting projects. Applications with licenses tied to physical hardware cannot transfer to cloud VMs without a licensing renegotiation. Workloads that require bare-metal I/O performance, such as high-frequency trading systems or certain database configurations, lose that performance on virtualized cloud infrastructure. Applications with hard dependencies on on-premises network appliances or proprietary hardware cannot be replicated through standard server migration tooling. And systems so tightly coupled to adjacent on-premises workloads that they cannot operate independently are better candidates for replatforming or refactoring before any cloud move.
Conclusion
Lift and shift migration is the fastest way to move workloads to the cloud, and the data supports it as a mainstream strategy. The average rehost migration produces a 40.06% cost reduction, and measurable savings typically appear within four months of cutover. Those outcomes are achievable, but only when the execution follows the full sequence: workload assessment, dependency mapping, controlled replication, a clean data freeze, and disciplined post-migration right-sizing.
Start by identifying which applications in your estate are straightforward rehosting candidates: those with stable workloads, no licensing constraints, and clearly mapped dependencies. Applications with hard hardware ties or undocumented couplings to adjacent systems belong in a separate track for replatforming or refactoring. That assessment determines your actual scope, and scope determines whether your budget and timeline hold.
Comments