Home>All Insights>Why you shouldn’t lift-and-shift legacy software to the cloud (and what to do instead)

Why you shouldn’t lift-and-shift legacy software to the cloud (and what to do instead)

Like most organisations, you’ll likely be part-way through an overall move towards the cloud. Businesses and public sector bodies often begin these journeys by building greenfield functionality in the cloud, to meet newly emerging requirements. The core, long-in-the-tooth legacy applications, meanwhile, remain on-premises. However, there comes a time in every organisation’s cloud journey, when these complex monoliths also need to move.

These applications will generally be important or even critical to the smooth running of your organisation. Risk-aversion is therefore often the order of the day. As a result, a lift-and-shift of the application in its current state to a like-for-like cloud environment, is often the preferred approach.

The problems with legacy application cloud lift-and-shift

While the reasons for doing it are understandable, the lift-and-shift tactic is far from ideal. At best, it will unlock some benefits, such as reducing or eliminating data centre usage, and freeing you of hardware maintenance responsibilities. But on its own, it won’t unlock many of the other cloud advantages your organisation will be expecting, having either read about them, or experienced them around greenfield applications you’ve built.

And at its worst, an application lift-and-shift can result in higher costs and myriad other problems that are difficult to even diagnose, let alone solve.

This is because most legacy applications weren’t designed with cloud architecture in mind. For example, they won’t be built to flexibly scale horizontally, meaning you can’t dynamically add or remove capacity in line with changing loads. Instead, you may be forced to provision very large cloud servers, the same way you do on-premises – only now you’ll be hit in the pocket every month for them, even when they’re not fully utilised.

Finding middle ground between lift-and-shift and a full rebuild

That said, going to the other end of the spectrum and rebuilding your entire application to be cloud-native, is something that many organisations won’t have the budget or inclination to attempt.

So how do you migrate your complex legacy software to the cloud, in a way that unlocks the benefits you and your business want, without unacceptable cost and risk?

Below, we explore how to find middle ground that strikes the right balance, by strategically carving off and refactoring selected parts of the application.

Define your cloud goals

Start by identifying the big challenges and risks that the legacy application(s) are causing your organisation. Also pinpoint any opportunities that you’d like to go after, but where some kind of application-related constraint is holding you back.

Typical challenges might include:

  • You lack flexibility when it comes to creating new products, services and user experiences
  • You’re struggling to keep your website or customer portal available or performing well under large and sometimes unpredictable loads
  • You need to tighten up security in certain areas
  • Particular business tasks are taking too long, or processes are inefficient due to the way the application works
  • You’re seeking to reduce costs

By setting out what these key problems and opportunities are, you’ll by extension be able to establish which parts of the application stack to focus your immediate attention on.

Next, conceptually divide up your application stack into pieces that can be separated along clear boundaries. This could be horizontal (front-end, API, database), or vertical (if you’re a retailer, this could be your channels for web, mobile, call centre and bricks-and-mortar stores). Mapping the components in this way enables you to identify and prioritise enhancements in each area, while avoiding the need to rebuild everything from scratch.

Once you identify what you need to improve, you can look to detach the relevant components from the monolith, by specifying and building clear interfaces and separations of responsibility. Patterns such as the strangler fig or anti-corruption layer enable you to build modern cloud services that interface with legacy components.

To provide some inspiration on how this can work in reality, we’ve outlined a few examples below, to give you a flavour of ways you can go about this.

Tactical improvements that unlock cloud benefits

Enabling dynamic scaling

Let’s say you run a web application that sees significant load spikes throughout the year. You’re currently running it on a very large server, like the one we touched on earlier. Despite this, you’re experiencing slowdowns and outages at peak times, while for the rest of the year, this size of server isn’t needed. In this situation, splitting the application functionality, such that large single servers can be replaced by multiple smaller resource pools, would enable you to scale each component dynamically in line with demand. This would provide opportunities to optimise costs, provide high-availability and achieve greater operational flexibility.

Supporting rapid user interface improvements

Splitting the user-facing elements off from the more-business-critical back-end, and communicating via an API, is an effective way to enable rapid, safe enhancements to your user interfaces. It means you can apply modern, automated deployment techniques to the front-end, decoupling it from the lengthy release cycles required when making changes to the underlying business-critical systems.

Leverage cloud monitoring

Benefit from the fact that you’re using a connected set of services, by feeding your logs into a cloud monitoring tool such as AWS CloudWatch or Azure Monitor. This enables you to combine them with metrics from each service to generate dashboards and alerts, giving you greater insights into the behaviour of your stack, without costly manual integrations.

Use feature-rich cloud services

Cloud services offer plenty of functionality out-of-the-box. For example, if you have a bespoke on-premises login system for user accounts, migrating them into a service such as Azure AD B2C could unlock a range of new functionality such as multi-factor authentication, federation and bring-your-own-identity, at the push of a button.

Get the right skills

Shaping and delivering the cloud journey for complex, business-critical legacy applications demands a breadth of expertise. If your organisation is relatively new to this aspect of cloud migration, it can be beneficial to bring in external support. This is an effective way of both accelerating your cloud migration in a controlled way, and of upskilling your own teams in cloud technologies and architecture.

And of course, once you’ve established a footprint in the cloud, your use of cutting-edge technologies will be a major attraction for potential recruits – the importance of which can’t be understated in today’s highly competitive job market.

To explore more about how you can use cloud as a force for good in your organisation, get your free copy of our digital leader’s guide to modern cloud today.