Introduction
Lift and shift migrations were sometimes frowned upon in the past. Mainly because they fail to unlock the benefits of cloud and can result in higher costs. But increasingly people understand that there is a place for this approach in the migratory mix. As Amazon Web Services (AWS) explains:
Most migrations happen in phases to minimize risk and speed up time to production. The most common approach is to lift-and-shift (also known as “rehost”) an application and its data with as few changes as possible. This enables the fastest time to production. Once on AWS, it is easier to modernize and rearchitect application elements, leveraging cloud services and optimizations that provide the most significant benefits.
In other words, the speed of lift and shift means there are times when it is the best way to get an application to the cloud. As long as you modernise it afterwards.
So, how do you determine whether lifting and shifting is right for a given application?
Here are three situations where the approach is probably the best way forward, and three where it would be better to look at alternatives.
Three Situations Where Lift and Shift is the Right Approach…
When faced with time pressure to leave a data centre or on-premise environment.
This is the classic lift and shift scenario. When you’re faced with a hard deadline, such as data centre closure or a hardware refresh, it may be the only feasible option.
In these circumstances, it’s likely that a large portion of the estate needs to move to the cloud quickly. There’s no time to modernise or rebuild. What’s more, you’ll need to minimise the ‘migration bubble’ where on-premise and cloud hosting costs overlap, inflating spend. A lift and shift might not leverage cloud benefits straight away, but it gets everything in the right place. Once this phase is complete, work on modernising the applications can begin in earnest.
If there’s a requirement for expansion, but the team lacks experience with cloud-native technologies.
When there’s an imminent need for increased storage or new compute platforms, but your current data centre will not be fit for purpose, a lift and shift can be an effective solution. It’s the most straightforward route to the cloud as well as being fast. Costs will be high, but this might be acceptable short-term if it means those immediate business needs are addressed, and the business can continue to grow.
In these circumstances, the physical migration should be followed closely with phase two work involving cloud modernisation and staff development. Expert technical support, training and mentoring, and continuous improvement will be key to longer term success.
When you have an application that you want to modernise, but don’t have enough documentation to refactor it yet.
Refactoring is one of the cornerstones of effective cloud migration. Cloud engineers deconstruct existing applications or processes into smaller elements with fewer dependencies to foster agility. It also presents opportunities to eradicate technical debt and enhance specific areas with cloud-native tools and approaches.
To get this right, cloud engineers need to understand how the application was built and how it works. They’ll require documentation about the existing set-up, or access to people who have been directly involved with it. If the necessary information isn’t readily available, a lift and shift can be the most pragmatic way forward. Once the application is in the cloud, it can be prioritised for optimisation, or perhaps even replaced, later.
…and Three Where it isn’t
When you have time to refactor.
On the other hand, if you have the time and documentation needed to refactor, it should happen during migration not after. A lift and shift could result in unnecessary cost management problems, not to mention performance and agility issues. Refactoring an application ensures it takes advantage of cloud benefits from day one.
It’s worth noting that refactoring doesn’t have to involve rebuilding or recoding an entire application. Certain parts of its architecture can be improved, with cloud-native features adopted where they will be most advantageous.
We consider refactoring a central component of the ‘Evolve’ pathway to the cloud (see below diagram). As part of a phased migration, it gets you closer to a cloud-native state sooner than a lift and shift followed by a refactor. Further improvements will be necessary, but you can start enjoying some cloud benefits straight away.
When you don’t have cloud-native skills, but can consider relocating.
If you do not have cloud-native skills already, you may struggle to manage your environment effectively following a lift and shift to the cloud. This can result in spiralling costs, and frustrations within the team as tasks that were seemingly trivial now require different approaches to troubleshoot and remediate.
A better approach could be to assess workloads on-premise, then modernise while moving them to the cloud with the help of a partner. This will be better for the bottom line, and it will also give your team the ability to learn while going through the move. It’s an approach that will continue to reap benefits long after the workloads have been migrated.
When you are migrating to reduce costs and improve agility.
Lift and shift is not a good option when the objectives for cloud migration relate to cost reduction and agility. Leveraging these benefits always requires changes to the infrastructure of applications. Costs will almost certainly be higher following a lift and shift than they were in the previous environment too.
Taking the Evolve pathway to the cloud costs more upfront than a lift and shift. But it results in better cloud cost management and agility. It’s important to ensure all stakeholders understand this, so that expectations are aligned. If the lift and shift approach is taken in this situation, the entire migration may be perceived as a failure.
Take a Phased Approach to Cloud Migration
The key to successful cloud migration is a pragmatic, outcome-focused mindset. It’s best to view the process as a journey with various phases and stopping points along the way. Opting for lift and shift is sometimes a good move, and sometimes it isn’t. But even a poorly considered lift and shift can be rectified later. It’s not the end; it’s just the end of the beginning.
Greg is a Consultant at Sourced Group with over 20 years of industry experience. This has primarily been in the areas of infrastructure management, end-user compute, virtualization, databases, and cloud computing. Greg worked with end point management and on-premise virtualization for many years before moving on to helping customers move to, and adapt to the cloud. Greg is passionate about serverless, and also helping teams transition from legacy ways of working. Greg has also been recognised as an AWS Ambassador since 2021.
