Old software is not automatically unsafe software. The more useful question is whether the business can still operate, recover and change it with control. A short evidence check can separate a maintained older application from a genuine continuity problem.
01
Old software and risky software are not the same thing
Imagine an internal order system built eight years ago. It still fits the business because it contains years of real operating knowledge: customer terms, approval rules, document formats and the awkward exceptions that never appeared in the original specification.
Replacing that system would not simply replace old code. It would require the business to rediscover those decisions, migrate the data and teach staff a new way to complete familiar work. A rewrite may eventually be right, but the age of the current application does not prove it.
A well-maintained older application can be safer than a newer one nobody understands. It may have business-owned accounts, supported dependencies, tested backups, a repeatable release process and a developer who knows how to investigate it. A two-year-old application can be a legacy problem when the only developer has left, production cannot be reproduced and nobody has tested recovery.
The difference is control.
02
Worry when ownership starts disappearing
The first warning sign is not an old framework. It is uncertainty about who can take responsibility today.
The business should know where the source code lives and who owns the repository. It should control the hosting, domain, DNS, database, file storage, email service, monitoring and important third party integrations. Administrative access and account recovery should not depend on a former employee's personal email address or a supplier who no longer answers quickly.
This does not mean changing every password on Friday afternoon. A rushed access change can interrupt a working system. Start by mapping the accounts, owners, recovery methods and people authorised to approve a change. Then transfer or rotate access in a controlled order.
If the system works but the business cannot control the things around it, the risk is already present. It is simply waiting for a supplier dispute, failed payment or expired credential to make itself visible.
03
Unsupported foundations need context, not panic
Every web application sits on other software: an operating system, web server, programming language, framework, database and a collection of third party packages. Those components have support lives.
The National Cyber Security Centre warns that weaknesses found in unsupported products can remain unpatched and may be exploitable by relatively low-skilled attackers. The current OWASP Top 10 also treats software supply chain failures as a major web application risk.
That does not mean every unsupported package creates the same emergency. Exposure and business consequence matter.
An unsupported administration tool available only through a tightly controlled internal route is a different problem from an unsupported public application that accepts files and holds personal data. A component used by one isolated report is different from the runtime serving every customer request.
Record the real versions first. Check official support information and known vulnerabilities. Then ask what can reach the component, what the component can reach and what happens if it is compromised or stops working.
The worrying state is not simply old. It is unsupported, exposed and poorly understood.
04
A backup is useful only when recovery works
An application can appear reliable because an automated job says the database was backed up last night. That message proves a process ran. It does not prove the business can restore the service.
Recovery may also need uploaded files, generated documents, configuration, encryption keys, scheduled tasks and a record of the infrastructure. Restoring the database alone can leave half the application missing.
The NCSC advises system owners to test and monitor backup data regularly. That test should answer a business question: can the important service be restored within an acceptable time, with an acceptable amount of lost work?
For the order system, a useful test would restore the application into a controlled environment, confirm that staff can sign in, find a recent order, open its documents and complete one critical journey. It should record what was restored, how long it took and which steps relied on knowledge that was not written down.
If nobody knows when the last restore was tested, treat recovery as unknown. A hopeful green tick is not a continuity plan.
05
Safe change matters as much as stable operation
Some legacy applications run for years because nobody dares to change them. That can look like stability until a payment provider retires an API, a certificate expires or a regulatory requirement changes.
Ask whether another developer could create a safe working environment, identify the version running in production and release a small change without editing files directly on the live server. There should be a route to test important behaviour and a way back if the release fails.
Complete automated test coverage is not a realistic entry requirement for every older system. Start with the journeys the business cannot afford to lose. For the order system, that might be creating an order, applying the correct price, generating its document and passing the approved record into finance.
External connections deserve the same attention. Payment services, email providers, identity platforms, courier APIs and certificate authorities all change. An application can remain untouched while the world around it moves on.
Monitoring should therefore cover more than whether the home page loads. Failed scheduled jobs, application errors, storage limits, expiring certificates and broken integrations need to reach a named person who can act.
06
Use a traffic light test before discussing a rewrite
A short assessment can separate a maintained older application from a continuity problem. The table is deliberately business-facing. It is a triage tool, not a substitute for a technical and security review.
| Status | What the evidence looks like | Sensible decision |
|---|---|---|
| Green | The business owns the code and accounts, important components are supported or controlled, recovery is tested, releases are repeatable and monitoring reaches a responsible person | Continue using the application and fund routine maintenance |
| Amber | Answers exist but need checking, one person holds important knowledge, restore tests are old, updates are slipping or changes carry too much uncertainty | Commission a focused health check and stabilise the weak areas |
| Red | Important access or source is missing, exposed components are unsupported, nobody can deploy safely, recovery is unproven or the application is already interrupting critical work | Protect continuity immediately, reduce exposure and create a controlled recovery and modernisation plan |
Most businesses will find a mixture. That is normal. A green backup position does not cancel a red ownership problem, and an unsupported package does not automatically make the entire application red.
Rank each finding by consequence and evidence. Fix what could stop the operation or prevent recovery first. Improvements and new features can wait until the business has a stable base for change.
07
Do not buy a rewrite to escape uncertainty
A complete rebuild can feel reassuring because it promises a clean start. It can also replace known problems with a new product, a data migration and a second list of unknowns.
The existing application may contain business rules nobody has documented. Staff may rely on reports, shortcuts and exceptions that only become visible when the new system fails to reproduce them. A replacement can still be the right choice when the workflow no longer fits, the technology cannot be supported sensibly or every useful change costs too much. It should be an evidence-based choice rather than a reaction to the word legacy.
Often the better first move is to stabilise. Secure business ownership, test recovery, add monitoring, document the release route and update the most exposed components. Then modernise one bounded part at a time where that reduces risk or makes future change easier.
This approach creates stopping points. The business can fund the work needed to regain control before committing to a larger programme.
08
What a useful health check should leave behind
The result should not be a frightening list of technical terms or a rewrite quotation wearing an audit as a hat.
A useful application health check should separate verified facts, reasonable concerns and unresolved unknowns. It should explain which issue could interrupt the business first, which risk can be reduced quickly and which decision needs more evidence.
It should cover source code and account ownership, hosting and deployment, framework and dependency support, data and backups, monitoring, security concerns, documentation, maintainability and the application's role in the operation. Its limits should be clear too. A short review cannot prove that every hidden defect has been found or recreate access that no longer exists.
The outcome is a prioritised route: continue supporting, stabilise, modernise in stages or plan a replacement.
Old software is not automatically a problem. Lost ownership, untested recovery and unsafe change are.
If your application still matters but the answers are uncomfortable, I can start with an Application Takeover and Health Check. I review the available technical and operational evidence, explain the findings in plain business language and give you a controlled next step before anybody commits to a rescue or rebuild.
Useful questions
Legacy software risk check
- Can the business access and recover every important account?
- Does the source repository match what is running in production?
- Are the operating system, runtime, framework, database and key packages supported?
- Which unsupported components are exposed to untrusted users or data?
- Has a complete restore been tested in a controlled environment?
- Can another developer create a safe working copy and release a small change?
- Are critical business journeys protected by repeatable checks?
- Are failures, expiring certificates and broken integrations monitored?
- Does every important alert reach a named person who can act?
- Is the next decision based on evidence rather than the application's age?
