The strongest business case for modernising a legacy system rests on three things: the operational risk of keeping it as it is, how hard it is to maintain and change, and the capacity it ties up in people who could be doing something else. Make each of those concrete with evidence from your own organisation, then ask for a first stage of work rather than the whole programme.
Why do legacy modernisation business cases get turned down?
A common reason is that they argue from technology. "The framework is out of date" and "the code is hard to work with" are true, but they don't tell a board what happens to the business if nothing changes. The system works today, so leaving it alone looks like the cheapest option.
The other common problem is size. A proposal to replace the whole system in one go asks the board to accept a large commitment with nothing usable until the end. A smaller first step that reduces a named risk is much easier to approve.
What are the risks of keeping a legacy system?
Doing nothing feels free, but it carries risks that are rarely written down. Spell them out for your own system.
Security and compliance risk
If the operating system, database or framework no longer gets security updates, newly found vulnerabilities in it won't be fixed by the supplier. That matters to auditors, to cyber insurance questionnaires, and to customers who ask about your controls in their supplier due diligence. Cyber Essentials, for example, requires software in scope to be supported and patched, so an unsupported system in scope can fail certification.
Be specific. Name the component, say when support ended or will end, and say who has asked about it.
Key-person risk
If one person knows how to deploy, fix or explain the system, the business depends on that person staying, staying well and being available. Ask what would happen if they left next month. If the honest answer is that nobody else could restore the system after a failure, that is a business risk in plain terms, and boards understand it.
Failure and recovery risk
Ask whether anyone has ever restored the system from backup, and when they last did. Old servers, undocumented deployment steps and hardware nobody can replace all lengthen an outage. Estimate what a day without the system would mean: orders not taken, invoices not raised, staff unable to work. Use your own figures for daily transactions, not industry averages.
Integration risk
Legacy systems often sit in the middle of other flows. When a supplier changes an API, a partner wants a new connection, or another system is replaced, the old one has to change too. If it can't, the business works around it with manual steps.
How do you show the cost of slow change?
A hard-to-maintain system also limits what the business can do. Collect evidence from the last year or two:
- Changes the business asked for that were refused or deferred because the system couldn't take them.
- How long a typical small change takes from request to release, and how much of that is waiting, testing or fear of side effects.
- Releases that caused incidents, and what each one disrupted.
- New channels, partners or products that were delayed by the system.
You don't need to turn these into money. A list of real requests with dates, owners and outcomes is often more persuasive than a projected figure, because each item can be checked.
What capacity does a legacy system tie up?
Legacy systems quietly consume people's time, and that time has an opportunity cost.
Developer and IT time
Look at how much of your technical team's time goes on keeping the system running: restarts, manual fixes, data corrections, patching around unsupported parts. That is time not spent on work the business has asked for.
Staff workarounds
Ask the teams who use the system what they do outside it. Re-keying orders into another system, exporting to spreadsheets to produce reports, checking figures by hand because nobody trusts them. Each workaround costs time every day and introduces errors.
Recruitment and retention
Older technology gets harder to hire for. If roles on the system have gone unfilled, or people have left partly because of it, include that.
Should you include return on investment figures?
Only if the figures come from your own data. A board will test every number, and an invented percentage saving undermines the parts of the case that are solid. Hours spent on workarounds, incidents logged against the system and changes refused are all measurable. Projected savings from a new system are forecasts, so base them on measured volumes and handling times, state the assumptions, and say how you will check them afterwards.
Where you can't measure something, describe it. "Finance re-keys every phone order by hand", with the number of orders a day and the time each one takes, is evidence. A made-up efficiency gain is not.
What should you ask the board to approve?
Ask for a first stage with a clear purpose, not the whole modernisation. A good first stage:
- reduces a named risk, such as moving off an unsupported platform or documenting and testing how to rebuild the server
- produces something useful even if nothing further is approved
- tells you more about the system, so later stages can be planned with real information
- has a decision point at the end, where the board sees the results and decides what comes next
Staged modernisation is easier to fund than a rewrite because each stage stands on its own, the old system stays in use while each stage is done, and the board keeps control of the spend. Our guide on whether to rebuild or modernise covers how to choose between the two.
Typical first stages include getting the code into source control with a repeatable build, adding monitoring and alerting, upgrading the platform to a supported version, or putting an API in front of the system so other systems stop reaching into it directly. For .NET applications, upgrading .NET Framework to modern .NET is often a stage in its own right.
What does a good modernisation business case contain?
Keep it short. A board paper of a few pages that a non-technical director can follow is better than a long technical document.
- What the system does, in business terms, and which teams and processes depend on it.
- The risks of leaving it as it is, each with evidence and an owner.
- The cost of slow change, as a list of real examples.
- The capacity it ties up, in hours, roles or workarounds.
- The options considered, including doing nothing, stabilising, modernising in stages and replacing.
- The proposed first stage, what it delivers and how you will know it worked.
- The decision you want now, and when you will come back with the next one.
Who should put the case together?
The case is stronger when the people who run the business process build it with the technical team. The technical team can describe the risks and the options. The process owners can say what the system costs them day to day and what they can't do. A director who has felt the problem is a better sponsor than any document.
If you need help assessing a legacy system or planning how to modernise it in stages, see our legacy modernisation service.
Email [email protected] with your brief.