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 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 datacentre or on-premise environment
This is the classic lift and shift scenario. When you’re faced with a hard deadline, such as datacentre 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 datacentre 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.
Here at DevOpsGroup, refactoring is considered 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.