Replace Legacy Software or Modernise It? A Practical Decision Guide

The clearest sign is cost. Say you spend more each year keeping the system alive than it would take to fix the real problem. Then you already have your answer. The other signs usually arrive together.

It’s too expensive to maintain

Legacy software too expensive to maintain rarely shows up as one big invoice. Instead, it hides in a support retainer with a specialist contractor and extended support fees for an old database. There’s also the server nobody dares to switch off. Add the hours your team spends on workarounds. That’s the real bill.

It won’t talk to anything else

Old software difficult to integrate is the most common complaint we hear. For example, the job-costing tool has no API, so someone exports a CSV every Thursday afternoon and re-keys it into the accounts package. Each re-key is a chance for an error, and each error costs a morning to trace.

One person knows how it works

If a single developer, or one long-serving finance manager, holds the only working knowledge of the system, you carry a key-person risk. Nobody has written the business rules down. They live in stored procedures and in someone’s head.

It runs on unsupported versions

This one isn’t optional. The NCSC’s guidance on obsolete products states that the only fully effective way to remove the risk is to stop using the obsolete product. Short-term mitigations buy time. They don’t fix it. Does the system hold client or personal data? Then your UK GDPR duty to keep it secure applies too, as the ICO’s guide to data security explains.

The safe way is in stages: understand what the system really does, move it piece by piece, prove the data, run old and new side by side, then switch. Each stage should be reversible until the final cutover.

1. Assess usage and dependencies. List every screen, report, scheduled job and export. Then find out which ones people actually use. We usually find features nobody has opened in years. Map what feeds the system and what reads from it, including that Excel file finance built in 2016.

1. Write down the business rules. Pull the logic out of the code and out of people’s heads into a short specification. A software requirements specification doesn’t need to be long. It needs to be right.

1. Use the strangler pattern. Build new functionality around the old system and move one area at a time. Route traffic to each new part as it’s ready. Martin Fowler describes this as the strangler fig application. It keeps the business running while the old core shrinks.

1. Migrate the data with verification. Clean it before you move it. Afterwards, reconcile record counts, totals and a sample of individual records between old and new. Sign-off comes from the people who own the numbers, not from the developers.

1. Run in parallel. Operate both systems for a full business cycle, such as one month-end or one payroll run. Compare the outputs line by line.

1. Cut over and switch off. Set a date, freeze the old system to read-only, and keep an archive you can query. Then decommission the servers. If you skip this step, you’ll pay for both systems for years.

Modernise in place or replace

This is the order we follow in legacy software modernisation work. When the right answer is upgrading the existing application in place, the same assessment feeds our application modernisation approach instead.

The numbers below are an illustrative example, not client data. Take a 90-person UK contractor running a bespoke job-costing system built in 2011, sitting on an unsupported database and a single ageing server.

Option A: keep it as it is

• Support contractor: £30,000 a year
• Extended support and hosting for the old server: £6,000 a year
• Manual re-keying: two people, 6 hours a week each, at £25 an hour, over 46 working weeks = 12 × 46 × £25 = £13,800 a year

That’s £49,800 a year, or £249,000 over five years. And it doesn’t price the security risk at all.

Option B: modernise and integrate

• One-off refactor, rehost and API integration: £90,000
• Ongoing support and hosting: £12,000 a year
• Remaining manual work: 2 hours a week in total, so 2 × 46 × £25 = £2,300 a year

Running costs come to £14,300 a year, so £71,500 over five years. Add the £90,000, and the total is £161,500.

Option C: replace with SaaS

• Licences: 40 users at £60 a month = £28,800 a year
• Implementation and data migration: £45,000
• Integration with the accounts package: £15,000
• Remaining manual work: 3 hours a week, so £3,450 a year

Running costs are £32,250 a year, or £161,250 over five years. With the £60,000 one-off, the total is £221,250.

What the numbers say

In this example, modernising saves about £87,500 against keeping the system and about £60,000 against the SaaS route. However, the result flips if the bespoke logic gives no real advantage. In that case, the SaaS product’s roadmap, support and security updates are worth paying for. Run the same three columns with your own figures. Then add a line for risk. An unsupported database holding client data has a cost, even when nobody invoices you for it.

Most failed replacements fail for the same few reasons, and none of them is the choice of technology.

The big-bang rewrite

Rebuilding everything and switching over on one weekend is the riskiest plan available. The new system never quite matches the old one, the deadline slips, and meanwhile nobody improves the old system because “it’s going away”. Move in slices instead.

Migrating dirty data

Duplicate customers, cost codes nobody uses, half-finished jobs from 2014. Move them unchanged and you’ve paid to rebuild the same mess on a new platform. Clean and standardise first. That sequencing is what made the fit-out integration above hold.

No documentation of what the system actually does

Teams often write requirements for the system they wish they had and forget the quiet jobs the old one does. For instance, the overnight job that flags retentions due, or the report the finance director checks every Monday. List those before you design anything.

Buying before you’ve fixed the process

A new platform won’t fix a broken approval chain. Redesign the workflow, then choose the tool. That’s why a business operations audit usually comes before any modernisation work we do.

We start with the business problem and treat the technology as the tool. As a business automation and operations partner, we’re vendor independent, so we weigh integrate, modernise, rebuild and replace on the same terms.

In practice, that means a short assessment of usage, dependencies and five-year cost before anyone writes code. For construction firms, where job-costing and CVR tools often run on old bespoke systems, our construction operations work covers the typical COINS, Sage and Procore combinations.

Business problem first. Technology second.

Not sure whether to replace, modernise or integrate your old system? Book a first consultation with Severus