Is Lift & Shift actually a quick and painless path to the cloud?

3 Reasons why Lift and Shift will cost you more in the end

Co-Authored w/ Michael Hodgdon

When our customers approach us about moving to the cloud, they are no longer asking why, they are asking how. In particular, two common themes have arisen over time:

· How do we get there?
· How quickly can we get there?

This post is not to answer these questions, but rather to shine a light on a common pitfall we often see: assuming a Lift & Shift strategy is a quicker and cheaper journey to the cloud.

Lift & Shift is exactly what it sounds like, taking an existing on-premise environment and applications, and directly moving to the cloud with no material change. Simply put, you’re treating the cloud as just another data center. This strategy misses on including any of the differentiating services that the cloud offers. Organizations typically choose this path because it’s perceived that re-engineering for the cloud is time consuming, not secure, more expensive and not necessary.

While the Lift & Shift strategy has its place as part of a comprehensive cloud migration approach, it should be limited to exactly that, a piece. As we’ll discover in this post, it does have hidden costs that should be considered.

Top 3 reasons to consider with a Lift and Shift Migration.

1. Arguments for Lift & Shift are all debunked
First, let’s continue to look at why Lift & Shift might on the surface be appealing.

· Faster to the cloud
· Less upfront investment
· Less disruption to developers and the business

These all sound like perfectly reasonable desires for your organization when making such monumental change in how your infrastructure is run, right? Let’s look at these advantages and break them down. They are not as straight forward as it might seem.

Faster to the cloud
Ask anyone who has gone through a Lift and Shift and they’ll tell you how ‘quick’ and on-time their migration completed. The fact is, legacy applications were not architected for cloud services and in most cases end up requiring partial or complete re-architecting just to meet the previous operating status quo.

Think about this example, we’ve had a client that architected their legacy applications on 32-bit operating systems. Come time for their Lift & Shift migration, they realized mid-stride that only 64-bit was available to them and could not successfully deploy the applications. This left them scrambling for resources to retrofit their applications and extended the timeline significantly.

Below are some common occurrences we’ve seen surface during Lift & Shift efforts and significantly slow down progress:

· Dynamic IP Addresses that change at any given time
· Bloated legacy applications
· Technical Debt
· Ephemeral Storage
· Session data with load balancing
· Deploying legacy configurations on new (cloud) hardware

Less up-front investment
We just demonstrated an example of unexpectedly having to allocate development resources, that were otherwise prioritized, to refactor a fairly common occurrence. Now, let’s factor in the other applications and hardware that has been accruing technical debt over the years. The stage has been set to be completely reactive to these issues instead of getting ahead of it. This means more people, more time, and ultimately more cost.

Even if you pull off the Lift & Shift unscathed, it almost always costs more than expected which we’ll describe in more detail later.

Less disruption to developers and the business
As you can see from the previous sections, this becomes an assumption based on debunked arguments, rather than a stand-alone reason. We can clearly see that developers will be constantly disrupted and stretched thin.

At the point of deadlines being in danger, extended or missed the business is now going back to stakeholders and customers to adjust schedules and explain why they’re off the mark.

By the time a Lift & Shift is all said and done, many applications can not only be re-engineered, but optimized for the cloud. In many cases doing so in less time and money than it would take to make a Lift & Shift work.

2. Lift and Shift gives you an infrastructure, but not a cloud infrastructure

When we look at our previous experiences and many other case studies under the Lift & Shift strategy, what it boils down to is lost opportunity. Sure, as we just discussed, in theory you can map a copy of your infrastructure to a cloud provider and it might be quicker than re-engineering, but it will be just that. A copy.

By doing this, you miss on the revolutionary capabilities that cloud provides. For example, scaling to meet the demands of your application consumption. You could have your environment configured to not only guarantee your applications are available to customers almost 100% of the time but, also grow and shrink your compute power based on demand … without your team making a single keystroke.

When you look at Lift and Shift, what it boils down to is lost opportunity.

You could save on cost plus reduce your management needs by deploying your application to services that don’t require server maintenance… this is known as serverless architecture.

These are just a few examples that scratch the surface of the possibilities available to us when utilizing cloud services to their potential. When integrated into your systems, you’re no longer migrating to just another data center, you’ll be building a cloud infrastructure.

3. Lift and Shift hits your wallet

Among these examples is a common thread — organizations are trying to save money and optimize resources. We’ve already seen several examples of unexpectedly bringing on more resources and pushing out or even missing timelines. All of which have significant costs.

The very nature of Lift and Shift and directly mapping to a cloud infrastructure means you could very well end up spending just as much or more on the monthly invoice

Let’s pretend those aren’t factors for a moment and the Lift & Shift succeeds unimpeded. There are still unnecessary costs that were hidden in the old data center. These costs range from over provisioning infrastructure capacity based on best guess estimates, to applications being artificially bloated and storage heavy after years of technical debt. The very nature of Lift and Shift and directly mapping to a cloud infrastructure means you could very well end up spending just as much or more on a monthly invoice, let alone compounded with the previous factors.

So if not Lift and Shift, what then?

The bottom line is there is no one strategy you’re going to be able to use to port your entire infrastructure and application portfolio. As you plan your migration to the cloud consider an adoption framework, such as The 6 Rs, while taking a honest look at your systems and break down the approach.

Ask questions. Here’s some good starters:

· Which applications are business critical and need to be firing at all cylinders at all times?
· Which applications have been architected well and could use a tune up?
Perhaps auto-scaling or cloud storage that is a better option than keeping data local?
· Which applications need to be sunset and rewritten?
· Which applications fit the Lift and Shift profiles outlines above?

When discussing migration models, this is a case where everyone is a unique snowflake and a Lift & Shift might be a component of the overall strategy, but it should remain that, a piece of a larger puzzle.