“Lift and shift” migrations have been praised for their simplicity, but there’s always a catch. Without careful forethought, you’ll find that your newly cloud-based application isn’t optimized for its environment. When your application costs more to run and crashes more often, there’s no advantage in putting it in the cloud.

How do you migrate in a more intelligent manner?

When Lift and Shift Goes Wrong

Lift and shift mishaps are more likely than you think. Research from Gartner predicts that between 2014 and 2019, roughly 50% of data migrations have gone wrong, resulting in delays or blown budgets. To put it mildly, there’s a lot that can go wrong.

As just one example, say that you lift and shift an application only to realize that there’s a dependency that wasn’t previously understood, or that simply went un-noticed. Either the application breaks because it was depending on something, or a host of applications break because they were depending on it. It’s back to the drawing board.

In terms of more subtle failures, you might simply find that your application doesn’t work well in its new home. One current example of this is SAP S/4HANA. S/4HANA is the newest iteration of the venerable ERP product, and it’s also cloud based. Businesses have been having severe difficulties porting their on-premises SAP implementations to the new version, in part because businesses tended to heavily customize the old version of the software – and those customizations simply don’t translate into the cloud. Even Under Armour, one of SAP’s flagship customers, has reported difficulties with the new software.

Finally, there’s always the chance that a lift and shift will end up migrating data that didn’t need to be moved – databases and dependent applications that aren’t in use, or those which are no longer provide value to the business either because they’re old or because they’re duplicates. This data still incurs costs: it needs to be stored, managed, and backed up.

Alternatives to Lift and Shift

What are a few alternatives to the lift and shift approach?

You could design a new application from scratch. Although this would likely be costly and impractical for systems of record, less mission-critical applications would probably benefit from a cloud native approach.

As an alternative to rewriting or an all new application, you could re-platform or refactor your existing application. The former involves cutting out some features of your application and then replacing them with newer alternatives – for example, replacing the existing database with a more cloud-optimized version. This gives the re-platformed application access to a large number of cloud features, allowing it to be more flexible and scalable in its new environment. As a drawback, however, organizations will have to accept that these changes will take a certain amount of time and testing.

Going the refactoring route means fundamentally changing the architecture of your application. This approach surrenders both the time and cost advantages of lift and shift and re-platforming, but by accepting this trade-off, the resultant application should be able to leverage nearly any cloud feature. This results in an application that is more scalable, flexible, and that requires less costly maintenance in the long run.

The critical path to refactoring looks like this:

• Perform a cost benefit analysis – do the long-tail savings from operating a refactored application cover the up-front costs of refactoring?
• Determine the scope of the refactor. If you need to rearchitect more than 50% of the application, you’re doing what’s called a complete refactor. It may make more sense to aim to the smallest amount of refactoring that get your application working.
• Find tools and learn how to use them. The forefront of cloud computing includes microservices, containerization, and Kubernetes. Understand how to adapt these technologies to your applications.
• Keep monitoring. If the first refactoring doesn’t take, you may have to do a second refactor while your application is in flight.

If the time, cost, and risks of a refactoring project seem daunting to you – or if the timing for a refactor just isn’t right – you might consider a smarter approach to lift and shift.

Lift and Shift – The Smart Way

Device42 offers a complete single pane of glass for your IT infrastructure. You have total visibility into your applications and their dependencies, and this includes applications that are hosted in VMs, in containers, in Kubernetes pods, and so on.

What this means for a lift and shift is that the painstaking process of isolating the application you want to move, auditing its dependencies, and separating it from redundant applications and databases… suddenly gets got a lot less painstaking. In other words, the immediate ability to see what will break when you move an application will make moving your application that much easier.

Once you are equipped to make more informed decisions about whether and how to move an application, you’ll also have a clearer path to your next step. This will make a successful migration outcome much more likely (and less painful), while greatly decreasing the possibility that you’d ever have to make a last minute decision to re-platform or refactor your application mid-flight – thus minimizing service disruptions for your customers.

Want to learn more about how Device42 can help your legacy apps find their new home? Contact us today!