lift and shift
Lift and shift is a strategy for moving an application or operation from one environment to another without stopping to redesign the app or operations workflow. The complexity of an application or operation is a key factor in deciding whether something should be lifted and shifted or re-architected from scratch as a new native cloud app or operation.
In the early days of cloud computing, the lift-and-shift approach was a common option for replicating on-premises apps in the cloud while avoiding costly, time-consuming re-design. However, many legacy colocation applications that were lifted and shifted to the cloud were not able to take full advantage of the cost-efficiencies of native cloud features, including autoscaling. While commercial, off-the-shelf applications with easily defined patterns were often good candidates for lifting and shifting, re-architecting was a better option for resource-intensive apps, such as those used for big data analysis and image rendering.
Lift and shift vs. refactoring
A common approach to lift and shift is to move an application to the cloud in order to reduce on-premises infrastructure costs in the short term, but then refactoring the app once it's in the cloud. Each approach has its own pros and cons.
Disadvantages of a lift and shift approach
Today, there are significantly more disadvantages to a lift-and-shift approach when compared to application refactoring, which is also known as rearchitecting. While it's usually best to refactor an application as part of a migration, sometimes organizations need to do so retroactively.
This article is part of
What is cloud migration? An introduction to moving to the cloud
Lifting and shifting is often compared to moving a houseplant from one environment to another; being in a different habitat can affect whether the plant will thrive. Likewise, an IT project that started in an on-premises or original legacy system might not work as well in a new location.
For example, a lift-and-shift project that starts without sufficient documentation of requirements or operational design can easily go awry. The unfortunate results often involve data that is mismatched to its handling systems or data sets that outgrow their environment. Resource-intensive apps may need to be redesigned from scratch as cloud-native apps to avoid performance and latency issues.
Refactoring may also be necessary when performance fails to meet expectations after a lift and shift, especially when tuning doesn't solve the problem. An application that's been moved to the cloud may also benefit from refactoring when bills are unexpectedly high due to application or database inefficiencies or when security vulnerabilities arise because the application can't integrate with native security systems, such as identity and access management tools.