What Are The Signs That Your Legacy System Needs Replacing?

Almost nobody replaces a system because it stopped working. Systems get replaced because something outside the building forces the issue.

A client sends a supplier questionnaire. An acquirer asks who owns the code.

A vendor publishes an end-of-support date, or the one developer who understands the thing hands in their notice.

The scale of the problem is now documented rather than anecdotal. The UK government’s State of Digital Government Review, published in January 2025, found that an average of around 28% of central government technology estates were classified as legacy, ranging from 10% to 60% across organisations.

In the private sector, a 2025 survey of 250 UK CIOs, heads of IT and risk managers reported that 90% of UK firms carry Windows technical debt and 51% had already suffered downtime linked to it.

This article gives you ten signs with a commercial consequence against each, the end-of-support dates that should already be in your diary, a scoring method, and a structure for the business case. Every claim is linked to its source.

Why Does Nothing Get Done While the System Still Works?

Because working and safe are different things, and only one of them shows up in the day-to-day. The replacement conversation loses to something more urgent every year until an external event removes the choice.

The Evidence That This Is Normal

The government review found that organisations including DWP and NHS England spend as much as 70% to 85% of their technology budgets on upkeep rather than modernisation or innovation.

The Commons Science, Innovation and Technology Committee returned to this in Rewiring the State, published on 3 June 2026, which repeated the 28% figure and added that there is no complete record of the scale of legacy IT across central government.

Around 15% of respondents to that work could not estimate their own legacy footprint at all. If a government department cannot answer the question, a 40-person manufacturer with one long-serving developer is unlikely to be in better shape.

What Actually Forces the Decision

Replacement decisions are almost always triggered externally, and the trigger usually arrives with a deadline attached. Knowing which triggers apply to you tells you how much notice you are likely to get.

Trigger	Who usually raises it	Typical notice you get
Vendor publishes an end-of-support date	Your IT supplier or an internal sysadmin	12 to 36 months, if anyone is watching
Client supplier security questionnaire	A major customer’s procurement team	2 to 6 weeks to respond
Cyber Essentials renewal or a framework bid	Your own certification body	Fixed annual date
Acquisition or investment due diligence	The buyer’s technical adviser	2 to 8 weeks inside a deal timetable
Resignation or retirement of the sole maintainer	The person handing in their notice	1 to 3 months
A security incident or a near miss	Nobody, until it happens	None
A contract you cannot bid for	Sales, informally, usually too late	Already lost

Why the Cost Stays Invisible

The spend on keeping a legacy system alive is spread across licences, hosting, contractor invoices and staff time, so no single line item ever looks alarming. Nobody adds it up because adding it up is nobody’s job.

That is the same pattern the Cloudhouse State of Technical Debt 2025 report describes, in which only 14% of the UK organisations surveyed were prioritising investment in fixing legacy systems.

Treat that as a vendor-sponsored survey rather than independent research, because it is one. The direction of the finding still matches what we see on the ground.

Which Outdated System Symptoms Should Trigger a Replacement Decision?

Ten signs matter more than the rest, because each one has a measurable commercial consequence: lost certifications, lost deals, staff hours spent rekeying data, and a single point of failure sitting in one person’s head. You do not need all ten, and three or four is usually enough to justify an audit.

1. The Vendor No Longer Supports the Version You Run

Out of support means no security patches, no bug fixes, and no help when it breaks. You are running it on your own liability.

This applies to your platform as much as your application. Microsoft ended support for .NET Framework 4.5.2, 4.6 and 4.6.1 in April 2022, and 4.6.2 reaches end of support in January 2027.

Ask your IT team or supplier for one thing in writing: the version number of every component, and its published end-of-support date. If nobody can produce that list, you have found a second problem.

2. One Person Understands It, and They Are Near Retirement

If a single named individual is the only route to changing your core system, that is a business continuity risk rather than an IT one. It also tends to be the sign that boards understand fastest.

It shows up in mainframe COBOL, in VB6 applications written in the late nineties, and in Delphi systems that still run a warehouse. The people who wrote them are in their late fifties and sixties, and the replacements are not coming.

The test is simple: if that person left on Friday, how long until someone else could safely make a change? Where the honest answer is months, a system takeover by a second party is usually cheaper than the risk you are currently carrying for free.

3. Small Changes Take Months and Cost More Than the Work Is Worth

When a change any modern system would absorb in a day turns into a three-month project, you are paying interest on technical debt. The interest is charged in changes you stop asking for.

Adding a field to a form, changing a VAT rate, altering a report layout: these are trivial jobs. If your last three change requests each ran past a month, the problem is not the developer.

Look back at the last year of requests and count the ones quietly dropped because the estimate came back too high. That count is a better diagnostic than any code quality symptom you can measure.

4. It Cannot Integrate With Anything, So Staff Rekey Data by Hand

Manual re-entry between systems is the most visible outdated system symptom and the easiest to cost. It is also the one your finance director will recognise immediately.

No API, no webhooks, no supported export beyond CSV. So somebody in finance types the same order into two systems, and somebody in operations reconciles them on a Friday afternoon.

Two staff spending half a day a week each on rekeying, on £35,000 salaries, is close to £7,000 a year in wages alone. Add employer National Insurance and pension and you are nearer £8,300 to £8,500, before you count a single error.

5. It Will Not Pass a Security Assessment or a Client Questionnaire

IASME, the NCSC’s official Cyber Essentials delivery partner, is blunt about this. Its published guidance states that any company using unsupported software in the scope of the assessment will fail to achieve certification.

Larger clients now send supplier security questionnaires as standard, and public sector frameworks frequently require Cyber Essentials as a condition of bidding. One unsupported component in scope is enough to stop you, which is why a software security assessment is worth running before a client runs one on you.

6. It Runs on an Operating System That Stopped Getting Patches

An application tied to an unpatched server is exposed regardless of how good the application itself is. The attacker does not care which layer you neglected.

Windows Server 2016 reaches end of extended support on 12 January 2027. Anything still on Windows Server 2012 R2 or 2008 R2 passed that point years ago.

The NCSC’s guidance on obsolete products is unusually direct. It sets out ways to reduce the risk through isolation and monitoring, then states that the only fully effective way to mitigate this risk is to stop using the obsolete product.

7. Mobile and Remote Access Is Impossible or Bolted On

If people can only use the system from a desk in one building, it is shaping how your business operates rather than supporting it. That constraint compounds every time you hire.

Remote desktop sessions into a Windows application, VPN clients that break whenever someone updates a laptop, engineers filling in paper because the system will not load on a phone: these are workarounds with a running cost.

Ask what your field staff and home workers actually do instead. The answer is usually paper, WhatsApp, or a spreadsheet nobody backs up, and all three are cheaper to replace with a web application or a mobile app than to keep tolerating.

8. Every Report Starts With an Export to a Spreadsheet

When the answer to any management question is a CSV export and a pivot table, you do not have reporting, you have a monthly data-entry exercise. It is slow and it is a week out of date by the time it reaches the board.

It also creates an unmanaged copy of your data on somebody’s laptop. Under UK GDPR those uncontrolled copies are still your responsibility, and the ICO’s guidance on data security expects you to know where personal data is held.

The commercial cost is decision latency. If you cannot see margin by customer until the middle of the following month, you are steering by a rear-view mirror.

9. Downtime Is Getting More Frequent and Recovery Takes Longer

The trend matters more than any single outage. Rising incident frequency in an unchanged system means the environment around it has moved on.

Track two numbers over the last twelve months: how often the system was unavailable during working hours, and how long it took to restore. Both climbing points to a hardware, dependency or knowledge problem that will not fix itself.

Then ask the question nobody enjoys. Has anyone actually tested a full restore from backup, onto hardware you could still buy today?

10. It Is the Reason You Cannot Take On a Piece of Work

The most expensive sign is the one that never appears on an IT report: the contract you did not bid for because the system could not do it. Nobody logs a ticket for revenue that never arrived.

A client wants a customer portal. A distributor wants EDI, and an acquirer wants consolidated reporting across two entities.

Each time, the answer is that the system will not stretch that far. This is the sign that turns a technology conversation into a commercial one, and it is usually the one that finally gets a modernisation budget approved.

How Urgent Is Each Sign?

Score them rather than counting them. Business risk is what a non-technical director should worry about, technical risk is how hard the underlying problem is to fix, and urgency combines the two.

Sign	Business risk	Technical risk	Urgency
Vendor no longer supports your version	High	High	Act within 6 months
One person understands it	High	Medium	Act now
Small changes take months	Medium	High	Plan this year
Cannot integrate, staff rekey data	Medium	Medium	Plan this year
Fails security questionnaires	High	Medium	Act now
Unpatched operating system	High	High	Act now
No mobile or remote access	Medium	Medium	Plan this year
Reporting means exporting to spreadsheets	Medium	Low	Plan next year
Downtime rising, recovery slower	High	High	Act within 6 months
Blocks a commercial opportunity	High	Medium	Act now

The legacy system replacement signs worth taking to a board are the ones scoring high on both columns. Two highs on the same row is a budget conversation, not an IT ticket.

Stuck with a system nobody wants to touch? SD:UK modernises legacy software without stopping the business

Which End-of-Support Dates Should Already Be in Your Diary?

January 2027 is a genuine cliff edge for UK businesses running Microsoft platforms, because Windows Server 2016 and .NET Framework 4.6.2 both stop receiving security updates within the same 24 hours. If your application runs on either, the date is already inside most procurement and delivery timetables.

The January 2027 Cliff Edge

Microsoft’s support calendar clusters. Windows Server 2016 and the .NET Framework versions tied to it end together, which means a single legacy application can lose its operating system, its runtime and its web server on the same Patch Tuesday.

For a mid-sized operational system, planning and delivering a re-platform takes longer than the notice remaining. That is the practical reason to look at the list now rather than in the autumn.

Dates Worth Checking Against Your Own Estate

This is not exhaustive, and it deliberately mixes Microsoft and open source because most UK estates run both. Check each against your own component inventory rather than assuming.

Two database dates catch UK businesses out in particular. SQL Server 2016 passed its end of extended support in July 2026, and SQL Server 2017 follows in October 2027.

Component	Support ends	What it means for you
SQL Server 2016	14 July 2026 (passed)	Already unsupported. Extended Security Updates available to July 2029 at a cost
PHP 8.2	31 December 2026	Security fixes stop. Common in older Laravel and WordPress estates
Windows Server 2016	12 January 2027	Takes IIS 10 and the System Center 2016 family with it
.NET Framework 4.6.2	12 January 2027	Tied to the parent operating system lifecycle
SQL Server 2017	12 October 2027	Plan the upgrade alongside any 2027 server work
Windows 10 (mainstream)	14 October 2025 (passed)	Devices are on borrowed time unless enrolled in ESU
Windows 10 Extended Security Updates	October 2028 (hard stop)	Three paid years maximum, price doubling annually

What Extended Security Updates Actually Buy You

ESUs are a delay with an invoice attached. Microsoft’s own programme runs for a maximum of three years past end of support for organisations, and the per-device price doubles in each of the second and third years.

They also buy you security updates only. No feature updates, no bug fixes, and no guarantee that your third-party software vendors will keep certifying against a platform they consider dead.

Using ESUs to buy planning time is reasonable. Using them as a strategy is the position the NCSC advises against, because isolation and monitoring reduce risk without removing it.

What Does a Legacy System Cost You If You Do Nothing?

Four cost lines, and the largest one is almost never documented: licences and support, hosting or hardware, specialist maintenance day rates, and staff hours lost to manual workarounds. Adding them up is what turns a technology grumble into a board paper.

The Four Cost Lines

• Licences, support contracts and any extended security update fees
• Hosting, or the amortised cost of on-premise hardware you cannot easily replace
• Specialist contractor or supplier day rates for anyone who can still touch the system
• Staff hours lost to rekeying, reconciliation, manual reporting and workarounds

The fourth line is usually the biggest and the least visible, because it is spread across people whose job titles say something else. Measure it for two weeks rather than estimating it.

A Worked Example

This is a composite of the shape we see in 30 to 80-person businesses, not a client’s actual figures. Substitute your own numbers, because the method matters more than the totals.

Cost line	Assumption	Annual cost
Legacy licences and support	Two products, annual renewal	£6,000
Extended security updates	12 devices, year two pricing	£1,500
On-premise server refresh	Amortised over 4 years	£2,750
Specialist contractor	8 days a year at £650	£5,200
Rekeying and reconciliation	2 staff, half a day a week, fully loaded	£8,400
Manual month-end reporting	1 finance day a month, fully loaded	£2,300
Total cost of doing nothing		£26,150 a year

A £26,000 annual run rate changes the conversation, because it is now measured against a project cost rather than against zero. That is the comparison a finance director will make anyway, so make it first.

The Number Nobody Puts on the Slide

The costs above are the ones you can invoice against. The one you cannot is the cost of a project that fails because nobody understood the old system before the replacement started.

Long-lived systems accumulate undocumented business rules, and those rules are the most common cause of a replacement programme overrunning. This is precisely what an audit is for.

How Do You Score Your System Instead of Arguing About It?

Score each of the ten signs from 0 to 3, add them up, and compare the total against a band. A number ends the argument between the operations director who wants it replaced and the finance director who does not.

How to Score

Zero means the sign does not apply. One means it applies mildly, two means it applies clearly, and three means it applies severely or has already caused a loss.

Score it with two people from different departments in the room, not one. Where the two scores differ by more than one point, the gap itself is worth discussing.

Sign	0	1	2	3
Vendor support	Fully supported	Support ends in over 2 years	Support ends within 12 months	Already unsupported
Key person risk	3 or more people can change it	2 people	1 person, not leaving	1 person, leaving or retiring
Change lead time	Days	2 to 4 weeks	1 to 3 months	Over 3 months, or refused
Integration	Documented API in use	API exists, unused	Files and scheduled exports only	Manual rekeying daily
Security assessment	Certified, no findings	Certified with caveats	Would likely fail	Has failed, or never attempted
Operating system	Current and patched	Supported, patched late	Support ends within 12 months	Unsupported
Remote and mobile access	Native and used	Works via VPN	Remote desktop only	Office desks only
Reporting	Self-service and live	Scheduled reports	Export and pivot table	Manual compilation
Downtime trend	Flat and rare	Occasional, quick recovery	Rising, slow recovery	Frequent, restore untested
Commercial blocking	None	One request declined	Two or more declined	A named deal lost

What Your Total Means

The bands below are a prompt for the next action, not a verdict. A high score on a system nobody depends on matters less than a moderate score on the one that takes your orders.

Total score	Reading	Next action
0 to 7	Healthy enough	Re-score annually. Fix the highest single line
8 to 14	Accumulating debt	Budget for remediation in the next financial year
15 to 21	Replacement window open	Commission an audit now, while you still choose the timing
22 to 30	Forced move likely	Treat as a live business risk and put it on the risk register

Any single line scoring 3 on vendor support, security assessment or operating system deserves attention regardless of the total. Those three are the ones that fail an external test rather than an internal one.

Which UK Rules Turn an Unsupported System Into a Compliance Problem?

Two, in practice: the Cyber Essentials scheme, where unsupported software in scope is an automatic fail, and UK GDPR, where the ICO has treated inadequate patching and outdated systems as a breach of the security principle. Neither requires an incident to have happened yet.

Cyber Essentials Is a Hard Fail, Not a Deduction

The scheme’s own published guidance states that any company using unsupported software in the scope of the assessment will fail to achieve Cyber Essentials certification.

There is no partial credit and no compensating control that rescues it. Either the software in scope is supported, or the certificate does not issue.

That matters commercially because many public sector frameworks and an increasing number of private supplier agreements require the certificate to bid. Losing it is a revenue event, which is why it belongs in the cyber security section of your risk register rather than the IT budget.

UK GDPR and What the ICO Actually Does

The clearest recent authority is the DSG Retail case. The ICO won its Court of Appeal challenge on 19 February 2026, and the matter was remitted to the First-tier Tribunal.

The point of law is the useful part for a UK business. The Court’s summary confirms a controller must protect personal data against unauthorised processing even where the third party processing it could not identify the individuals themselves.

Be careful how you cite this internally. The £500,000 penalty is not finally settled, and the DSG findings centred on point-of-sale malware and basic security failures rather than on legacy software specifically.

Supplier Questionnaires Are the Rule You Meet First

Most businesses encounter none of the above directly. They encounter a 60-question spreadsheet from a customer’s procurement team, with a section on patching and supported versions.

Answering honestly on an unsupported platform loses the renewal. Answering optimistically creates a contractual misrepresentation, which is worse, and is one reason the security warranties in your own contracts deserve a read before you complete one.

How Do You Turn These Signs Into a Business Case the Board Will Approve?

Board approval comes from three numbers, not ten symptoms: what doing nothing costs each year, what the risk exposure is worth, and what revenue the system is currently blocking. Symptoms belong in the appendix.

Cost of Doing Nothing

Use the four cost lines from the worked example above, with your own figures and your own assumptions stated in the open. The credibility comes from showing the working, not from the precision.

Present it as an annual run rate rather than a total. A recurring number is harder to defer than a one-off one.

Risk Exposure

Price the things that have not happened yet: a failed Cyber Essentials assessment that removes you from a framework, a UK GDPR breach involving an unpatched server, a week of downtime with no supported route to recovery.

You do not need actuarial precision. Multiply a plausible cost by a plausible annual likelihood and show your assumptions, because boards accept that when the reasoning is visible.

Opportunity Cost

List the deals, contracts and efficiencies the system has blocked over the last two years, with a value against each. Framed as revenue enablement rather than IT housekeeping, this is the section that gets digital transformation funded.

Technical debt is a genuine constraint, but it is not an argument a commercial director will fund on its own. Blocked revenue is.

The One-Page Structure

• One paragraph on what the system does and what depends on it
• The annual cost of doing nothing, with the four lines shown
• Risk exposure, with cost multiplied by likelihood and assumptions stated
• Opportunity cost, listing named blocked deals and their value
• The three options with indicative cost and timescale: refactor, re-platform, replace
• The recommendation, the decision needed today, and the date it expires

Keep the detail in appendices, including the scoring table and the component inventory. If you need help pricing the options, our guide to software development costs and the bespoke software cost breakdown give defensible ranges.

Need an independent view before you put it to the board? Talk to us about a technical audit

What Should You Do Before Committing to a Replacement?

Audit before you decide. A short technical assessment of what you actually have tells you whether the answer is refactor, re-platform or full replacement, and stops you buying the most expensive option by default.

What the Audit Should Cover

• An inventory of every component and its support status, with published dates
• Who holds the source code, and whether it builds from scratch today
• What the data model looks like and how clean the data actually is
• Which integrations exist, official or otherwise, including the ones nobody documented
• What the system does that nobody has written down
• Who can currently change it, and what happens if they leave

That fifth point catches people out, and it is the reason a technical due diligence exercise pays for itself. Undocumented business rules are the most common cause of a replacement overrunning its budget.

In our delivery experience an assessment of this kind takes one to three weeks for a mid-sized operational system, depending on how much documentation exists. Our guide to technical due diligence costs sets out what drives that range.

Then Pick a Route

Replacement is not automatically the right call. Plenty of systems that look hopeless from outside have a sound data model and a well-structured core, and cost far less to modernise in stages than to rebuild.

Route	What it does	Best when	Typical duration
Refactor	Keeps the system and improves the code and structure	Core logic is sound, more than one person understands it	6 to 16 weeks
Re-platform	Moves it to supported infrastructure without rewriting logic	The platform is the problem, not the application	4 to 12 weeks
Re-architect	Splits or restructures the system while retaining behaviour	It works but cannot scale or integrate	3 to 9 months
Replace	Starts again on current technology	Nobody can change it, or the business model has moved on	6 to 18 months
Retire	Turns it off and moves the data elsewhere	A newer system already covers most of the function	4 to 10 weeks

The durations above reflect SD:UK delivery experience on mid-sized UK systems rather than any published benchmark. Most sensible programmes mix routes, which is what legacy software modernisation means in practice.

If you want the underlying concepts before choosing, our explainer on what legacy software modernisation is covers the definitions and the strategy options in more detail than this article does.

Where the Code Is the Blocker

Sometimes the constraint is not the platform but the state of the codebase itself, or a supplier relationship that has broken down. That is a code rescue problem before it is a modernisation one.

Getting a second party able to build, deploy and change the system is often the cheapest first move available. It removes the key person risk without committing to a rebuild, and it is what a fractional CTO will usually recommend first.

When Should You Start, and In What Order?

Work backwards from your hardest external date, then subtract the audit, the procurement and the delivery. For a January 2027 platform deadline on a mid-sized system, that puts the start date in the past.

Working Backwards From a Date

Take your earliest fixed date, whether that is an end-of-support day, a certification renewal or a contract bid. Then subtract each stage in turn and see where you land.

Stage	Typical elapsed time	Runs in parallel with
Technical audit and component inventory	1 to 3 weeks	Nothing. This comes first
Business case and board approval	2 to 6 weeks	Supplier shortlisting
Procurement and contracting	3 to 8 weeks	Requirements capture
Requirements and discovery	3 to 6 weeks	Procurement
Build or re-platform	6 weeks to 12 months	Parallel running preparation
Data migration and parallel running	4 to 12 weeks	Training and cutover planning

These are SD:UK planning figures rather than published benchmarks, and the build row is the one that varies most. Use them to test whether a date is achievable, not to promise one.

What to Sequence First

Deal with the things that fail an external test before the things that annoy your staff. A failed certification stops revenue, whereas a clunky report costs time.

In practice that usually means the operating system and any unsupported components first, often as a move to supported cloud infrastructure, then integration, then the user-facing rebuild.

Getting the requirements right for that final stage is where most of the value is won or lost, and our guidance on capturing business requirements and building a project delivery plan covers how.

Choosing Who Does It

Legacy work rewards suppliers who have done it before, because the risk sits in the parts nobody documented. Our guide to choosing a software development company sets out the questions worth asking.

Ask for a comparable engagement rather than a capability statement. Our Composite Legal Expenses case study is an example of what that evidence should look like.

Related Guides

Related: What Is Legacy Software Modernisation?

Related: Software Technical Due Diligence Costs Explained

Related: What Is a Software Security Assessment?

Related: How Much Does Bespoke ERP Software Cost?

Related: How Much Does Bespoke CRM Software Cost?

Related: What Is Bespoke Software?

Frequently Asked Questions