There are several ways to migrate to the cloud today — None of which are an equal path to modernizing on-premises applications and workflows. Lift and shift migration promises cost savings, speed, and less effort compared to other cloud migration strategies.
But are these claims true? In this guide, we’ll cover whether a lift and shift migration strategy actually saves you money and effort when migrating to the cloud. We’ll also take a deeper look at what lift and shift is, when you might use the migration strategy, and other strategies you may want to consider.
Table Of Contents
Lift and shift migration involves moving your application as-is from an on-premises or local data center to cloud infrastructure with minimal, if any, modification.
This migration strategy allows you to migrate data and workflows without changing the app's core architecture. You just change the infrastructure that supports it.
For these reasons, lift and shift is also referred to as rehosting or the forklift cloud migration strategy.
The approach does not include decoupling an application from its operating system. A lifted and shifted application is not a cloud-native application. Lift and shift means you copy your application from on-premises architecture and “paste” it into a cloud platform.
It is mostly a matter of matching your existing application's compute, networking, and storage requirements to the cloud platform's resources. It is even easier to implement when the application is already virtualized (using virtual machines).
There are several companies that have used lift and shift to move to the cloud. One common practice is to rehost in the beginning and then improve systems from that point forward.
Its meteoric rise was triggered by an incident in 2008 when a data center corruption made purchasing DVDs impossible for three days.
Netflix knew that retaining its monolithic architecture would hinder its growth and cause more downtime in the future. This prompted it to digitize its workflows so that it could become more flexible and resilient.
The Netflix architecture on AWS has since improved to support cloud-native features such as autoscaling and microservices.
GE Oil & Gas planned to migrate 500 applications from its pipeline inspection machinery to Amazon Web Services (AWS) by the end of 2016.
The company also wanted to eliminate legacy business processes immediately in order to cut IT costs. However, it had to migrate all 750 terabytes of data with a great deal of speed. By the end of the year, the company achieved these goals, including a 52% cost savings.
Dow Jones, which is one of the world's largest news gathering companies, had only two months to relocate from a local data center in 2014.
At the time, CIO Stephen Orban favored refactoring to migrate the company’s workflows.
But time was not on his side. So they rehosted most of what they had in the data center to AWS within two months and saved $40,000 while at it.
Dow Jones then used replatforming to help optimize its workflows in a cloud environment.
News Corp owns Dow Jones. Dow Jones' lift and shift move impressed its parent company with its cost savings and speedy transformation. The company set a bigger goal; transferring 75% of all applications to the cloud and saving $100 million.
The company reduced the number of data centers from 56 to just six after the migration.
These examples highlight some excellent lift and shift use cases. But let’s take a look at a few more.
Here are a few scenarios where you may realize the advantages of a lift and shift migration strategy.
Like Netflix, you can use the lift and shift method to migrate to a more resilient platform and mitigate future risks. Alternatively, as Dow Jones did, you can lift and shift an existing application before you need to vacate a data center or are about to terminate your lease.
Lifting and shifting means you take a copy of your application and data and move it to a cloud platform with minimal modifications. You may still have to reconfigure the host when you move to a new cloud environment. However, the approach requires minimal time and investment compared to other migration strategies.
Like GE Oil and Gas, lifting and shifting existing workloads can help begin your digital transformation. By planning and executing correctly, you can rehost your applications efficiently and with minimal disruptions.
You can begin introducing changes to the core architecture of applications once your IT operators become more accustomed to the new platform. Thus, they can support cloud-native features such as scalability, real-time database backup, pay-per-use pricing, and reduce back-end management.
Rehosting’s pay-per-use model can also help convert capital expenditure (CapEx) to operating expenditure (OpEx). By becoming a cloud customer, you will pay low monthly fees based on how much of the cloud provider's resources you use over a specific period.
This method would be the most effective alternative to buying, maintaining, and replacing computer equipment in a local data center.
Decoupling an application you bought off-the-shelf from a third party can be tough. When refactoring is not possible or would corrupt the app, a lift and shift migration can help maintain its integrity. The application's familiar workflows would remain intact.
On the flip side, you can lift and shift an application when it is easy to change its core architecture later.
So when the time is right, or you have the funds, talent, experience, or other solid business cases for making the move, you can move forward. You wouldn't have to waste your time to find a cloud-based solution that fits your needs.
There are several ways to save IT costs with the lift and shift approach.
But there is a reason this cost savings point came last.
In the long run, keeping a rehosted application as-is can raise cloud costs by 15%. Since lifted and shifted workloads are not cloud-optimized, overprovisioning compute resources can be a costly and recurring challenge.
That can erode the cost savings you’d hoped for.
“A proliferation of hidden costs during the lift and shift project can happen,” Bill Buckley, VP of Engineering at CloudZero, seconds the findings.
“Everyone always thinks of getting the core code running and figures, ‘we can just re-package it for the new environment.’ But you often forget about the multitudes of supporting projects to build, test, debug, etc.
Those concerns often cannot be fully lifted and shifted, and thus need some serious work, and companies sometimes start it too late, so the overall lift and shift of the core code slows down tremendously,” Bill confirms.
This begs the question.
There are cases when lift and shift can be a useful strategy. Long-term, however, it might not be an optimal move. So, what are some disadvantages of the lift and shift method in cloud migration?
Here are three recurrent issues with the lift and shift approach, according to Bill Buckley, VP of Engineering at CloudZero.
When running in different environments, you’ll see various failures. Most companies have an architecture that has been “battle-tested” in its current environment.
When it’s thrown into a new environment, the new failures can cause a fragile end product that performs much worse for your end-users.
One of the hardest things an engineering team has to do at scale is delivering nearly uninterrupted service to end-users. Many of the tools and practices that allow your team to do that arise out of years of practice on the current technology stack.
As with the first problem, new stacks of technologies may have their own observability pattern. You and the rest of your team may not keep track of what is going on and take action before an outage or breach occurs.
Yet 56% of decision-makers said in 2019 that they were “extremely concerned” about security when migrating to the cloud. Due to these observability issues, a lift and shift strategy may not inspire confidence.
This can be a problem if you migrate applications exactly as they are, with all existing vulnerabilities, cloud resource provisioning issues, and compatibility challenges that cause repatriation.
Some organizations roll back cloud migrations due to problems with resource provisioning and unexpected costs, for example.
When Arlington Research and Virtana surveyed 350 IT decision-makers in November 2020, 252 admitted they repatriated from a public cloud for these reasons:
You do not want to be a part of this group.
“Calculating COGs for new products before they are built is very hard, but when building a new product you can at least learn as you layer on features. You can’t do that as easily when doing a lift and shift, so I would be very conservative and figure out how to, early on, add-in project planning and tooling to see if your estimates are being met so that you don’t end up in a place where the sunk cost fallacy is pushing you to do non-ideal things later in the project.”
Bill Buckley, VP of Engineering
So, what are the alternatives to lift and shift?
There are different types of cloud migration, and then there are cloud migration strategies. The three categories of cloud migrations are:
Lift and shift is an IaaS migration because you are taking your on-premises application as-is and moving it to a new infrastructure — a cloud environment. You pay for the cloud infrastructure on a per-usage basis after that.
SaaS migrations involve replacing existing applications and workflows with ready-made commercial software. The approach is ideal for organizations experiencing rapid changes in their market and are unable to keep up because their internal talent is limited in terms of skills, experience, and numbers.
Many SaaS products come cloud-ready or take a cloud-first approach. Consider a scenario where you have been using custom CRM software on-premises but now wish to go to the cloud.
A Salesforce subscription may help you eliminate the need to find and hire cloud specialists to help you with your project.
There is a caveat, though, which is that you may or may not encounter some incompatibilities between your existing workflows and the functionality of a SaaS product. You would also have to integrate your CRM-based workflows with Salesforce. If that happens, a couple of otherwise solid workflows might have to be sacrificed.
Retraining your staff on using the new software might disrupt productivity and service delivery.
PaaS migration requires you to make some alterations to your application's code to make it as cloud-native as possible.
Usually, the goal is for the application to tap into cloud-native capabilities continuously. Scalability and automation are among such capabilities, as are serverless computing and microservices.
PaaS requires a more significant investment of time, money, and talent than lift and shift. Yet, organizations that implement PaaS efficiently recoup and exceed their investments over time.
There are several cloud migration strategies under PaaS, which we’ll cover below.
You’ll often hear about the 6Rs in cloud migration strategies. The following guide will explain one more way to the cloud; relocating.
Rehosting involves moving existing workloads to an IaaS without making significant code changes to your app. Lift and shift is a perfect rehosting example.
Relocating is similar to rehosting, except that it utilizes VMware Cloud to preserve your app's architecture even after moving it into a new cloud environment.
Relocating can be ideal for organizations that want to:
Check out our guide to choosing a multi-service approach vs multi-cloud strategy here.
In addition, you'll learn about vendor lock-ins and how you can avoid hampering innovation.
The advantage of this strategy over lifting and shifting is that it involves switching from on-premises applications to ready, cloud-optimized SaaS applications. Think: leaving your custom HR software for Workday.
In addition, SaaS may be helpful when you don't want to purchase or renew expensive licenses for the software you operate locally in a data center and would rather pay based on usage.
Rehosting can initially be more affordable and time-saving. But it can limit your application’s capabilities, such as portability and horizontal scaling. So replatforming improves on lift and shift by altering certain aspects of an application, so it becomes more cloud-optimized without rewriting its core architecture.
Refactoring involves making changes to an app’s architecture to take advantage of the latest cloud features, like autoscaling and microservices.
You can also rebuild an application from scratch.
The transitional phase of rebuilding demands more skills, time, and cash than lifting and shifting.
But building cloud-native applications also offers the highest potential, such as
It can also be an effective way to reduce your cloud costs without affecting application performance.
A hindering factor may prevent you from moving your business processes to the cloud. Some limitations may involve compliance or security concerns, applications that are extremely complicated to digitize, or migrations that don't make economic sense.
Nonetheless, these limitations could change, enabling you to digitize the application.
After switching to a more efficient cloud environment, you can retire the applications you no longer need. As a result, you save unnecessary costs and free up your developers to focus on adjusting and optimizing the app's performance for the new environment.
Those are the most common lift and shift migration alternatives.
Here is an AWS chart to help put these most common application migration strategies into perspective now that you are familiar with all seven migration techniques.
Migration projects are inherently challenging. They tend to take up a lot of political capital and actual business capital, at the very least, in opportunity cost. Whichever migration strategy you choose, Bill has a word of advice for you:
“Be very cynical of what cost savings you will get,” Bill continues.
“Calculating COGS for new products before they are built is very hard. But when building a new product you can at least learn as you start layering on features. You can’t do that as easily when doing a lift and shift."
“So I would be very conservative and figure out how to, early on, add-in project planning and tooling to see if your estimates are being met. That way, you don’t end up in a place where the sunk cost fallacy is pushing you to do non-ideal things later in the project.”
Keeping track of costs in new architectures can be a challenge because it is tough to always translate cloud costs to your business. You can see how much you’re spending with your cloud service provider but not why and how.
What drives your cloud spend? How do cloud costs map to your specific features and products? How much does each of your individual customers cost your business?
We purpose-built CloudZero for engineering teams to answer specific questions like these and more. With CloudZero’s cloud cost intelligence platform, engineering teams can drill into cost data from a high-level down to the individual components that drive their cloud spend — and see exactly what cloud services cost them the most and why.
Being able to see your costs in this way and track progress in real-time as you move to the cloud is vital to ensure profitability during your migration. Additionally, CloudZero also delivers automatic anomaly alerts and updates to engineering teams in Slack, so they'll know immediately if a change they made had unintended consequences — so you can adopt and experiment away.
Migrating your applications to the cloud goes beyond simply using a lift and shift approach — particularly if you are looking for cost savings. But without visibility, it's impossible to ensure you're making effective architectural decisions to optimize.
CloudZero gives you the cost visibility you need to migrate successfully. Request a demo today to begin monitoring costs in your new architecture.