How to Update Legacy Software: Options & Best Practices

There are many approaches to how you can update legacy software, and there’s certainly no shortage of advice on the topic. Every IT consulting and development company that has ever migrated a firm to a new CRM is preaching on how to modernize legacy solutions.

And though we have dealt with quite a few of such multi-year projects, we’ve decided to step back and see what the grand old men from McKinsey, Deloitte, and Gartner have to say on the matter.

In this roundup, we compare how these respected consultancies recommend approaching legacy system updating, weigh in with our insight on how their advice plays out in practice. And, of course, we’ll help you choose the most appropriate option to revamp software.

But before jumping to the topic, let’s ensure we’re on the same page about definitions. What is legacy software? It refers to older, often outdated, technology systems, applications, or platforms that are still in use within an organization. However, these systems may no longer be actively supported or updated by their vendors, making them difficult and costly to maintain.

Apart from the lack of vendor support and update, there are other signals to watch out for. Look at the signs below indicating that you deal with outdated legacy software:

• Inefficient performance and slow response times
• Difficulty integrating with newer technologies or systems
• High maintenance costs
• Reliance on outdated hardware or software components
• Limited scalability and inability to meet business needs
• Frequent system crashes, errors, or downtime
• Difficulty finding a skilled team familiar with the technology
• Incompatibility with current industry standards, protocols, or compliance regulations

Now, given these signs, it’s no wonder that many companies are compelled to do away with legacy technology. According to Statista, the top five reasons for such updates include enhancing security, improving overall system performance, reducing costs, and boosting integration capabilities. Convinced to consider transitioning to newer tech, too? Let’s see the ways.

McKinsey’s Way

McKinsey provides probably the most down-to-earth recommendations on how to update a legacy system. The company singles out three apparent approaches:

• Build a new system from scratch
• Refactor the existing system
• Replace with an off-the-shelf solution

Hopefully, these are self-explanatory, perhaps except for refactoring. As an example, if you decide to refactor an existing system, you’ll update its source code to remove any technical debt and make it easier to maintain. Or you may completely rehash, say, an accounting block in your legacy software and leave everything else intact.

Each of these three options, according to McKinsey, can be further divided into:

• Incremental — implies step-by-step changes to a system
• End-to-end — implies a complete system overhaul

As if not to sound too stiff or conservative, McKinsey goes on with two fancy models for IT transformation:

• Two-speed model
• Greenfield approach

The two-speed model is the most interesting. This approach ensures a relatively quick change to a particular part of legacy software. At the same time, the core platform is being revamped at a steady pace or even remains intact.

This way, the companies don’t have to interrupt their day-to-day operations to deal with modernizing their solutions. The development team issues incremental updates and keeps optimizing until the desired effect has been reached.

The greenfield option, as the name suggests, is focused on the complete replacement of a legacy solution.

Takeaways

So, it looks like McKinsey offers three options to overhaul legacy software: build a new solution, refactor an existing one, or buy a ready-made product. Plain and simple, right?

However, if you add the incremental and end-to-end approaches into the equation, you will see that there are way more variants.

And the two-speed or greenfield option is perfect for getting your management’s attention and getting them genuinely interested in updating the legacy software at your place. At the same time, these are not theoretical musings. We’ve applied the two-speed approach when helping an insurance company update its legacy system, bit by bit.

Gartner’s Options

When it comes to defining the most appropriate way of how to revamp a legacy system, Gartner is the one that goes into the most detail. Let’s take a look at the seven options that the company distinguishes:

• Encapsulate

  Gartner suggests that you extend your outdated system with APIs to serve data to other solutions built with modern technologies. This approach allows you to shift some operations to a separate high-performing platform while still relying on the legacy software as is.

• Rehost

  That’s a fancy name for moving a legacy solution to the cloud without any changes whatsoever or copying it to modern hardware.

• Replatform

  Let’s say your software lives on Linux OS, and you want to make it available on PCs or Macs. Updating the system so that it runs on Windows and Mac OSs would be re-platforming.

• Refactor

  The odds are you’ve already heard about refactoring. It’s the first thing you hear from architects and coders when they join to work on a legacy solution update. What they mean is they need to tidy up the code and make it more reusable and transparent. In the long run, refactoring can lower the cost of support and maintenance.

• Rearchitect

  This one is obviously about changing the architecture of a legacy platform. What the term usually implies is transferring monolithic legacy software to microservices or a serverless architecture.

• Rebuild

  That is the most doubtful option, as it suggests rebuilding the same solution — with the same scope and parameters. In reality, what happens more often is the next approach, and Gartner calls it…

• Replace

  When companies are looking for disruptive changes, they often choose replacement because new requirements can get them a completely new, no-longer-legacy solution.

Takeaways

Seven options, that’s where the real choice is, right? Wondering if you can also apply here the incremental and end-to-end multipliers from McKinsey? You sure can. It won’t necessarily make sense in all possible combinations. Still, theoretically, yes — you can arrive at 14 options using Gartner’s recommendations.

If we look at these alternatives from the point of view of changes to legacy software, though, we’ll notice something interesting. Rebuild and Replace are akin to McKinsey’s Build Anew & Replace, while Replatfrom, Refactor, and Rearchitect resemble McKinsey’s Refactor.

Encapsulate and Rehost, in their turn, do stand separately. They are often decent interim options, while a major rehash of a legacy system is taking place. We used these options to preserve a vulnerable piece of legacy software while developing a brand-new solution for a plant-growing company.

Deloitte’s Approach

Deloitte stands somewhere in the middle between Gartner and McKinsey in terms of how many options to modernize a solution it recognizes. There are five you can choose from:

• Replace

  Replacing involves either developing a new custom software system or installing a canned solution, which may also include data migration from the original software.

• Retire

  In case you no longer need the legacy software because of consolidation of applications or because it no longer holds actual data — remove it.

• Remain

  You can choose to do nothing and carry on with the legacy system without any updates.

• Retool

  Deloitte recommends retooling as a way of continuing working with your existing solution, once it has been updated accordingly: either through architecture or user interface modifications.

• Resource

  And if you can’t replace, retire, or retool your software, Deloitte suggests that you outsource or sell it to another company. This way, it’s no longer your responsibility.

Takeaways

We’ve never met companies seeking to retire or resource legacy software in our practice. Of course, the nature of our expertise probably has something to do with the fact, but it seems Deloitte includes the Retire and Resource options just to sound different.

The remaining (real-life) variants — replace and retool — we already know from the previous options, right? And as for Remain, well, give us a call, and we’ll share a couple of stories about the companies that decided to leave their outdated software intact.

How to Update Legacy Software Based on These Options?

As you can see, there are many options available for you. And when you are ready to make the decision, it will lie in one of these three dimensions:

So all of the options that we’ve just covered will fit into one of these larger groups. Let’s regard them through the prism of the goals you are trying to achieve and potential benefits.

And while we’re at it, let’s also put the option of building a new solution aside. Because let’s face it, “build anew” is a favorite option for many IT consulting and development firms. Yet, at Velvetech, we prefer not to underestimate the importance of reusing what you already have as much as possible.

What’s exciting about legacy software modernization is that in practice, such projects are often a mixture of all these different options. Reach out today to learn what will work best for your unique situation.

About the author

Henry Evans

Being involved in a spectrum of complex technology projects, Henry shares his all-round expertise on Veltetech’s blog to help companies advance their business with digital solutions.