There is a moment in every ERP advisory conversation that I have learned to listen for. It usually comes after an hour of talk about upgrades and roadmaps, and it goes like this: "We keep it alive with a mix of contractors and hope." Life support, in other words.
Life support is a legitimate position for a business to take, provided it is a decision and not an accident. The trouble is that most companies never take the decision. The system just stays, because replacing it is a project and keeping it is not. This article is about the risks that accumulate while you are not deciding, and how to assess them properly.
In this guide
The security exposure nobody budgets for
The government's Cyber Security Breaches Survey 2024 found that half of all UK businesses had experienced a breach or attack in the previous twelve months, and the figure rises to 70 percent for medium businesses and 75 percent for large ones. Your old ERP is not outside that picture. It is usually the easiest door in.
Old systems accumulate security risk in four ways:
- Unpatched vulnerabilities. Once a product leaves mainstream support, the vendor stops fixing security holes. Publicly disclosed flaws in old software become a shopping list for attackers, and there is no patch coming.
- Outdated authentication. Legacy systems often predate modern password policies, multi-factor authentication and session controls. A decade-old login screen is a weak front door on your most sensitive data.
- Forgotten connections. The integrations bolted on over the years have their own credentials, often stored in plain text in config files, and nobody remembers they exist.
- No monitoring. Old systems sit outside the security operations stack. If someone is inside the ERP, the alerts that would fire for the rest of the estate do not fire for it.
The National Cyber Security Centre's guidance on cloud security principles is worth reading even if you are not moving to the cloud, because it sets out the modern baseline for protecting business data. Apply those same principles to the ERP you already run and you will quickly see where the gaps are.
Data protection and the regulator's view
Your ERP holds customer records, employee data, payroll and financial history. Under UK GDPR, you are responsible for the security of that data regardless of the age of the software that holds it. The Information Commissioner's Office makes the expectation clear in its UK GDPR guidance for organisations: you must be able to demonstrate appropriate technical and organisational measures.
That word, demonstrate, is the problem for life support systems. When a data breach happens on a system running unsupported software, the investigation starts with questions like: when did support end? What was the risk assessment? What compensating controls were in place? A business that cannot answer those questions has already lost the argument, whether or not a fine follows. The reputational cost of a breach notice is usually worse than the financial one.
The vanishing knowledge problem
Every year an old system stays, the group of people who understand it gets smaller. The developer who wrote the customisations retires. The superuser who knew which report to trust moves on. The third party support house merges and its contracts change hands.
I have walked into businesses where the ERP ran on the working memory of one person, and that person had given notice. That is not a technical risk, it is an existential one. The system does not break on the day the knowledge leaves. It breaks six months later, when nobody can fix the first thing that goes wrong, and the business discovers that its recovery plan was a person, not a process.
Knowledge risk is hard to put on a spreadsheet, but it is real. If your ERP documentation is outdated, your key user count is one, and your vendor contract no longer covers the version you run, the knowledge is leaving faster than you think.
A food sector business asked me to review its ERP after an audit flagged a control weakness. The system was eleven years past end of support, running on hardware the vendor had stopped certifying, and the only person who could run the annual stock revaluation was a contractor on his second extension. The audit finding was not about software at all. It was about the absence of evidence: no risk assessment, no compensating controls, no succession plan. The business escaped a regulatory referral by months and spent the next year on a controlled migration. The audit finding, not the software, was what finally moved the board.
Audit, compliance and the evidence gap
For businesses in regulated sectors, the audit is where life support becomes visible. Auditors ask three questions about any critical system:
- Is the system supported by the vendor, and can you evidence it?
- How are changes controlled, and who approves them?
- If the system fails, how do you recover, and how long does it take?
Life support systems fail all three. The support contract is lapsed or downgraded, changes are made by the one remaining contractor with no change control, and the recovery plan is a hope. Auditors have seen this pattern many times, and they report it. A qualified audit opinion, or a regulatory finding, is a very expensive way to discover that your system needed replacing.
Building a legacy risk register
You cannot fix what you have not scored. Set aside half a day and build a simple risk register with four columns: risk, likelihood, impact, and mitigation. Score each out of five. The rows you want:
- Security breach through an unpatched vulnerability
- Data loss or corruption with no reliable restore test
- Key person departure removing the only system knowledge
- Vendor support withdrawal or price shock
- Audit or regulatory finding on the system
- Outage during a peak period with no recovery path
Anything scoring four or above in either column deserves action this year. That action might be a compensating control, an extended support agreement, or the start of a migration programme. The register is also the document your board and your auditors will want to see, because it turns "the system is old" into a scored, evidenced position.
If the register points toward migration, the practical route is in the migration checklist nobody talks about, and if the destination is a modern platform, moving your back office to the cloud without losing sleep covers how to get there in stages.
Frequently asked questions
Is it legal to keep running unsupported ERP software?
Running unsupported software is not illegal in itself, but it can breach your duties under UK GDPR if a data breach results, and it may breach contractual or regulatory obligations in sectors such as food, pharma or financial services. The legal exposure comes from the incident, not the software.
What are the main risks of keeping a legacy ERP on life support?
The main risks are security exposure from unpatched vulnerabilities, data protection breaches, loss of the knowledge needed to run the system, rising support costs, and audit or compliance failures when you cannot evidence control of the system.
How do I assess the risk of my old ERP?
Build a simple risk register covering security, data protection, availability, knowledge and compliance. Score each on likelihood and impact, then prioritise the two or three highest scores. That register becomes the evidence base for the replacement decision.
Can I extend support for a system the vendor has ended?
Some vendors sell extended support for a premium, often two to three times the normal fee and for a limited window. It buys time but does not remove the risk, because security patches for old products are rarely backported. Treat it as a bridge, not a destination.
The honest summary: life support is a decision, not a default. Score the risks, evidence your position, and if the register is red, let it do the arguing for you.
