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 software.
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 update legacy software.
McKinsey’s Way to Modernize Legacy Software
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 legacy 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 legacy system
- End-to-end — implies 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 update 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 legacy solutions. The development team working on updating parts of a legacy system 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.
So it looks like McKinsey offers three options to update legacy software: build a new solution, refactor existing one, or buy a ready-made product. Plain and simple, right?
However, if you add up 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 to Update Legacy Software
When it comes to defining the most appropriate way for how to update a legacy system, Gartner is the one that goes into most detail. Let’s take a look at the seven options that the company distinguishes:
Gartner suggests that you extend your legacy 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.
That’s a fancy name for moving a legacy solution to the cloud without any changes whatsoever or copying it to modern hardware.
Let’s say your legacy 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.
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.
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.
That is the most doubtful option for how to update legacy software, 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…
When companies are looking for disruptive changes, they often choose replacement because new requirements can get them a completely new, no-longer-legacy solution.
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 on how to update legacy software 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 Way to Update Legacy Software
Deloitte stands somewhere in the middle between Gartner and McKinsey in terms of how many options to update a legacy system it recognizes. There are five you can choose from:
Replacing involves either developing a new system or installing a canned solution, which may also include data migration from the original software.
In case you no longer need the legacy software because of consolidation of applications or because it no longer holds actual data — remove it.
You can choose to do nothing and carry on with the legacy system without any updates.
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.
And if you can’t replace, retire, or retool your legacy software, Deloitte suggests that you outsource or sell it to another company. This way, it’s no longer your responsibility.
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 legacy software intact.
How to Update Legacy Software Based on These Options?
As you can see, there are many options available to update your legacy software. And when you are ready to make the decision, it will lie in one of these three dimensions:
|Build a new solution|
So all of these options to modernize legacy software 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.
Legacy Software Update Options
|Automate new or changed business processes||Replatform||Faster service delivery. Let’s say your field workers are demanding for a mobile app that allows them to serve customers right from where they are.|
|Retool||Optimal use of resources. Let’s say you automate an onboarding process for your customers: that frees your workers.|
|Replace||Budget economy. You replace legacy software with a canned solution that covers all workflows at your company. That’s often a more budget-conscious option.|
|Enhance the productivity of an existing system||Rearchitect||Improved stability. Switching to a microservices-based architecture improves your legacy software performance noticeably and makes it more stable.|
|Refactor||Lower maintenance cost. Legacy software with refactored source code requires less attention and is easier to maintain.|
|Hibernate an existing solution and make it more secure||Rehost||Protect your business as you gear up towards proper legacy software modernization.|
|Make legacy software available for light integrations with other systems||Encapsulate||An interim solution to enable new workflows. Let’s say you want to hook your legacy software with a new accounting solution you’ve deployed.|
|Sell the business, so legacy modernization is someone else’s headache||Retire||Well, if you are on this route, there’s but a tiny chance you’re reading this. Anyways, I encourage you to give us a call or fill out the form below and hear your options to update legacy software. It doesn’t need to be a headache.|
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.