For many large-scale corporate and government organisations dealing with legacy applications, a ‘lift and shift’ seems like the ideal way to migrate from physical servers to the cloud.

A lift and shift can be faster and easier to complete than comparative migration approaches that involve re-writing or re-architecting applications.

In other words, for many senior IT professionals, it’s easy to see a lift and shift migration as the quickest way to the cloud.

In reality—as with most tools or approaches—there are specific scenarios where a lift and shift is the ideal way forward.

So, how do you determine whether a lift and shift is right for you? How can you be sure this approach will provide the most value for your organisation and customers?

Ask yourself these crucial questions and the answers will help to guide your approach.

Firstly, before we even consider a lift and shift—or any other migration approach— it’s worth broadly asking: Why?

’Why should we engage in a migration project? What do you hope to achieve?

It’s critical to establish clear understanding and strong alignment. When your team can clearly articulate the purpose of the migration project and the measures of success, we can better determine our approach as a collective.

There are many ways to formalise the ‘why’. In past projects, like a large-scale lift and shift of 55 sophisticated tax applications for a UK government entity we’ve used tools from product management practices. One common example is a value proposition canvas.

Imagine your Development and Operations teams are your ‘customers’. In a workshop, we should agree on a series of hypothesis statements:

After you’ve developed and agreed on some meaningful hypothesis statements, you’ll better understand your goals. And therefore, we can determine whether a lift and shift is the best way to help you achieve those goals.

So then, what is a lift and shift?

A lift and shift involves taking an existing application that resides on physical infrastructure and moving it to a new hosting environment. Typically, it’s shifting applications from physical servers to the cloud.

In contrast to other migration approaches—like rewriting or re-architecting—a lift and shift does not involve any changes to the applications. Nothing is altered or improved throughout the migration process, aside from how and where the applications are hosted.

Hence the name: you ‘pick up’ the legacy applications in their current form (lift) and simply move them to a new environment (shift).

Before engaging in a lift and shift, you need to ask yourself these questions:

1. Have we confirmed that customers actually use and appreciate the applications we intend to migrate?

There’s very little value in moving something that nobody uses.

Firstly, you need to determine: how many customers use each application on a daily basis? How many use the applications in peak periods?

We typically employ a mixture of tools like Cisco’s AppDynamics, Google Analytics and facilitated user research practices to identify two things:

• The number of customers engaging with each application
• The way in which they engage with those applications

Armed with this information, you can also determine whether specific applications are meeting customer needs, or whether those needs are able to be satisfied elsewhere.

For example, do customers avoid or ignore a specific application because it’s easier to visit the customer service desk instead? Or, do they avoid a certain application because they can achieve the same result in an easier way through another application?

With this information, you can start to meaningfully consider:

2. Which applications do we actually need to re-home? How should we move each application specifically?

Due to the lift and shift’s perceived reputation for being easier and more time efficient than other migration approaches, there’s a general misconception that everything should automatically re-home to the cloud as standard practice.

In reality, once you have quantitative and qualitative information about customer interactions with each application, you’re far better placed to decide:

1. Whether you spend more time rewriting specific applications to provide an improved customer experience as part of the rehoming process
2. Whether you migrate the application in a way that ensures it’s easy to provide a better customer experience in the future
3. Whether you consolidate features from one application into another app that resonates better with customers, based on usage data
4. Whether you decommission the application entirely, and save money on the cost associated with rehoming it at all

These answers will help you to determine the best approach for each individual application involved in the migration programme. Ultimately, we don’t necessarily need to migrate everything. Even if we do, we can adopt a mix of migration techniques within the one suite of works.

It may sound surprising, but there’s also no harm in completely descoping an application from a proposed lift and shift migration.

If an application is old but working well, is robust enough to perform over time, and the maintenance or physical infrastructure associated with supporting that app is not going to become cost-prohibitive, there’s no need to fix something that isn’t broken.

3. Will we have an order of magnitude in projected operational cost savings once the migration is complete? Are we sure those savings will materialise?

Broadly speaking, there are three primary motivations for a lift and shift migration:

1. A desire to migrate to the cloud in general
2. A desire to make it easier to support applications in the future
3. A desire to save on infrastructure costs.

While a successful lift and shift will always deliver on the first two objectives, the third isn’t necessarily guaranteed.

If you don’t create significant savings on your infrastructure—and equally sizable reductions in general costs or time required to release future changes—the cost of a lift and shift can actually outweigh the savings associated with the move.

You need to carefully weigh up the entire cost of the migration program and compare it with the estimated savings you’ll recoup on completion.

Remember, take a holistic approach to calculating your prospective cost savings; total savings are often far greater than the reduction of spend on physical infrastructure. Try to factor for the benefits you’ll experience through:

— Eliminating the cost of any licensed platforms
— Eliminating the cost of support via third party suppliers
— Reducing ‘cost of delay’ by more rapidly releasing features and updates to support your customers

4. How do we ascertain the prospective cost of what needs to be moved and compare it with the projected value we will gain? How do we prioritise what moves first?

We often use an effort-versus-value matrix.

It’s an approach our team used particularly effectively while re-homing 55 complex legacy tax applications from physical servers to the cloud.

For each application involved in your project, ask yourself: What is the quantifiable effort associated with a shift?

Critically, you should base all estimated effort on the assumption that each app is the first one being moved. Why? Because the first application you migrate is always the most time-consuming and technically challenging. In this scenario, pessimistic estimations are typically more accurate than optimistic ones; any effort you estimate that isn’t required is ultimately a benefit.

Then look at the value of each application—what will you get out of that specific migration? In our example, we prioritised an application with multiple integration points and constant high volumes of user traffic. We prioritise and create a roadmap, and use that roadmap to plot when we can see value.

By completing the more complex migrations first, you realise the majority of the value. That’s because you typically solve the most sophisticated technical challenges early on and pave the way for those learnings to apply to all subsequent—and therefore smoother—app migrations.

From there, you can re-evaluate whether the effort of moving particular applications matches the value of the migration. At that point though, you can also reduce estimations of effort based on the accumulation of knowledge being leveraged from the earlier, more complicated migrations.

As the perceived effort of migrating each app is reduced, so is the value.

Ultimately, you’ll reach a point where the effort outweighs the value. That in itself is another clear signifier to ask once more: do we need to move everything as part of this migration?

In conclusion

While moving everything to the cloud may seem advantageous, it’s worth stepping back to consider your organisational goals, both long and short term.

Take the time to ask yourself some key questions, establish meaningful answers, and you may identify opportunities to save money in the long run by leaving certain applications as they are.

By all means, turn off any on-premise infrastructure that will save money in the long run, via total cost of ownership.

Otherwise, don’t be afraid to leave things as they are; especially if they’re still running and meeting a need, and particularly if you don’t have a cost-prohibitive long-term datacentre contract.

Your priority shouldn’t always be to get to the cloud as quickly as possible, because the grass isn’t always greener.

It is always greener, however, when you manage and consolidate those things that unlock new revenue streams and unearth cost savings. By asking yourself the above key questions, you’re better placed to identify exactly what those things are.

Contact us!

We hope you find this useful. For more information about lift and shift migration or the HMRC project take a look at our HMRC case study.

If you’d like us to share our experience with you, please get in touch in the form below.