What is lift and shift migration?
Lift and shift versus rehost migration
Lift and shift and rehost migration generally describe the same approach. The application, data, operating system, and main dependencies move to a new hosting environment while the application architecture remains largely unchanged.
The target environment changes. The application logic usually does not.
A rehost migration still requires preparation. Teams may need to review operating-system compatibility, storage, networking, identity, access controls, licensing, backup, monitoring, and connections to external systems.
What changes and what stays the same?
During a lift and shift project, the target cloud infrastructure may include new compute resources, storage, networks, security controls, databases, and operational services.
The following elements may remain largely unchanged:
Application code
Core data flows
Business processes
User interfaces
Application components
Existing integration logic
This makes lift and shift different from refactoring or rearchitecting. Those approaches involve significant changes to the way the application is built or operated.
Where rehost migration fits in a cloud migration strategy
Rehosting is one option within a wider cloud migration strategy. Other approaches include replatforming, refactoring, rebuilding, replacing, retaining, or retiring a workload.
The best choice depends on the condition of the application, the business deadline, the expected future state, technical dependencies, available skills, compliance requirements, and the value of modernization. Migration strategies should be selected for each workload rather than applied uniformly across an entire application estate.
Organizations planning a move can use network design architecture consulting when connectivity, routing, latency, segmentation, or dependency mapping affects migration feasibility.
When rehost migration fits a cloud migration strategy
Time-sensitive infrastructure moves
Lift and shift may fit a project with a fixed deadline, such as:
A data-center closure
An expiring hosting contract
Hardware reaching the end of its life
A change in regulatory requirements
A need to establish a disaster-recovery environment
A business decision to reduce on-premises infrastructure
In these situations, the immediate objective may be to move the workload safely. Application modernization can follow once the workload runs in the target environment.
Applications with manageable dependencies
Rehosting is easier when the application has known dependencies, supported operating systems, portable databases, and clear ownership.
Virtual-machine-based workloads are often considered for this approach because the application can move with its existing operating environment. That does not make every legacy application suitable. Hardcoded network assumptions, local storage, outdated middleware, licensing restrictions, and unsupported components can create additional work.
When another strategy may fit better
Replatforming may be a better choice when a limited change can improve performance, security, cost, or operations. For example, a team may move a database to a managed service while keeping most of the application unchanged.
Refactoring or rearchitecting may make more sense when the business needs major improvements in scalability, release speed, resilience, or maintainability. Retaining the workload may be more appropriate when migration costs exceed the expected benefit or when regulatory and technical constraints prevent a safe move.
Benefits for application migration and workload migration
Faster movement with fewer application changes
The main benefit of lift and shift is the limited change to the application itself. Teams spend less time redesigning code, replacing components, or rewriting integration logic before the move.
This can reduce the initial migration effort and make it easier to organize large programs into manageable phases. It does not remove the need for discovery, testing, security reviews, or cutover planning.
Lower disruption during application migration
Keeping the existing application structure can reduce the number of user-facing changes introduced during application migration.
The project can focus on transferring the workload, configuring the target environment, validating dependencies, and managing the cutover. Depending on the application and migration method, teams may use replication or parallel environments to reduce downtime. There is no universal downtime outcome. It depends on the data, architecture, cutover design, and level of testing.
A transition step for workload migration
A workload migration can involve more than one application. It may include databases, file stores, network connections, identity services, scheduled jobs, monitoring, and third-party integrations.
Lift and shift can provide a transition point for this wider move. Once the workload is stable, the organization can review its cost, performance, security, operations, and future requirements before deciding whether further modernization is worthwhile.
Limitations of lift and shift in cloud infrastructure
Existing technical debt moves with the workload
Rehosting does not automatically fix slow code, weak security controls, complex dependencies, manual processes, or outdated components.
A workload that was difficult to support on premises may remain difficult to support in the cloud. Moving the application changes its hosting location, while many of its underlying problems remain.
Limited cloud-native benefits
An unchanged application may not take full advantage of managed databases, automatic scaling, event-driven services, serverless capabilities, or other cloud-native options.
The workload may also require larger virtual machines than expected because its architecture has not been adjusted. This can affect operating costs and reduce the financial benefits of the move.
Performance, compatibility, and security risks
Teams should assess:
Network latency between application components
Data transfer requirements
Firewall and routing rules
Authentication and identity dependencies
Operating-system compatibility
Licensing conditions
Backup and recovery procedures
Security controls and exposure
Third-party integrations
Storage and database behavior
A successful transfer of files or virtual machines does not prove that the application works correctly in its new environment.
Migration cost and operating cost are different
Lift and shift may reduce the upfront work required to migrate an application. It does not guarantee a lower total cost after the move.
Cloud charges can increase because of oversized resources, licensing, data transfer, storage, backup, monitoring, or constant compute usage. Teams should compare the expected cloud operating cost with the current baseline before approving the strategy.
Migration planning before the move
Discover applications and dependencies
Migration planning should start with an inventory of the workload and its dependencies.
Document:
Application owners
Business importance
Data sources and destinations
Upstream and downstream systems
Authentication requirements
Network paths
Storage and database dependencies
External suppliers
Recovery expectations
Compliance constraints
Dependency mapping helps teams decide whether a workload can move independently or needs to be grouped with other systems in the same migration wave.
Prepare the target environment
Before cutover, the target environment should have the required compute, storage, networking, identity, access controls, backup, security, and monitoring capabilities.
Teams should define who owns each part of the environment and how issues will be escalated during the move. Capacity and cost assumptions should be tested before production traffic is transferred.
Define cutover and rollback conditions
A migration plan should specify:
The cutover sequence
Data synchronization requirements
The expected maintenance window
Validation steps
Communication responsibilities
Rollback conditions
The person authorized to stop or reverse the migration
Migration waves work best when they group related applications and dependencies around business priority, risk, and operational constraints.
What happens after a lift and shift migration?
Validate the migrated workload
Post-migration validation should confirm that the workload operates correctly in the target cloud environment.
Tests may cover:
Core business functions
User access and authentication
Data integrity
Application integrations
Response times
Network connectivity
Security controls
Backup and recovery
Monitoring and alerting
Resource consumption
The results should be compared with agreed acceptance criteria and the baseline established before the move.
Review the next step
After stabilization, the organization can decide whether to keep the workload as it is, replatform selected components, improve operations, or start a broader modernization project.
This decision should consider business value, technical debt, cost, risk, future demand, and the expected lifetime of the application.
Lift and shift is best understood as a migration technique. It can move a workload quickly, but it does not automatically modernize the application or improve its long-term operation.
Organizations dealing with complex connectivity, hybrid environments, or application dependencies can use network design architecture consulting to support the target environment and migration planning.
When network design architecture consulting supports the migration
Network expertise becomes relevant when the application depends on several environments, locations, suppliers, or security zones.
Typical concerns include:
Connectivity between on-premises and cloud resources
Routing and firewall configuration
Bandwidth and latency
Network segmentation
Private access to cloud services
High availability and failover
Application dependency mapping
These factors can determine whether a workload can move as planned and whether users will experience acceptable performance after cutover.
Mantu’s network design architecture consulting can support organizations that need to assess connectivity, define the target network environment, and prepare the infrastructure around a cloud migration.
Lift and shift migration can be a sensible choice when speed, continuity, or infrastructure exit takes priority. Its value depends on workload fit and preparation. The teams that benefit most treat rehosting as a deliberate transition, validate the result after cutover, and make a clear decision about modernization afterward.
