What This Is
Legacy software support is maintaining a system that your business depends on but that no one wants to rebuild. The work is keeping it running, fixing bugs, applying security patches, and making careful changes without introducing instability. This is the work of keeping old software alive, not modernising it. If you want to replace the system, that is legacy modernisation. If you just need it to keep working, this is the right service, and it sits alongside our other services for businesses that already have something worth protecting.
Every business reaches a point where a critical system is old enough that the original developer is gone, the documentation is sparse, and the technology is unfashionable. But the system works. It processes orders, tracks inventory, manages clients, or handles some essential workflow that the business cannot operate without. Replacing it would be expensive and risky. So it needs to be maintained, carefully, by someone who understands the risks of changing code that no one fully understands.
This is unglamorous work, and most agencies avoid it because it is not billable at premium rates and it requires patience rather than speed. We do it because we understand that the system you have is often more valuable than the system you wish you had, and keeping it running reliably is a legitimate engineering outcome.
When You Need This
Legacy software support is the right service when:
- Your system works well enough and a rebuild is not justified, but it needs ongoing bug fixes, security patches, and occasional small changes
- The original developer is no longer available and you need someone who can take over a codebase they did not write
- The system runs on an older technology stack that your current team does not have experience with
- You need security patches applied to an application that uses outdated dependencies or frameworks with known vulnerabilities
- Small feature requests come up occasionally, not enough to justify a new project, but enough to need a developer who knows the system
- You have a compliance or regulatory requirement to maintain and patch the system even though it is end-of-life in your roadmap
This is not the right service if the system is fundamentally broken, architecturally unsound, or causing more problems than it solves. If maintaining the system costs more than replacing it, legacy modernisation or custom software development is the better path. We will be honest about when maintenance stops being worth the investment.
How We Work
Taking over a legacy system starts with understanding what we are working with. We run a codebase audit that maps the architecture, identifies the risks, and establishes what can be safely changed and what should not be touched without significant testing.
We learn the system before changing it. The first engagement with a legacy codebase is read-only: we trace the data flows, identify the dependencies, map the deployment process, and understand the test coverage (or lack of it). This audit takes one to two weeks depending on the system’s size and produces a risk map that guides all future changes.
Changes are small, tested, and reversible. Legacy systems are fragile precisely because they are not well understood. We make changes in small, isolated increments with rollback plans. Bug fixes are verified against the specific scenario that caused them. Feature additions are scoped to minimise the surface area of change.
We add safety nets as we go. When we work in an area of the codebase, we add tests for the behaviour we are touching. The point is not to hit coverage targets, but to give ourselves (and you) confidence that future changes will not break what we just fixed. Over time, the most frequently modified areas of the system become the most tested.
What You Get
- Codebase audit documenting the system architecture, technology stack, risk areas, and deployment process
- Bug fixes investigated, tested, and deployed without introducing new issues
- Security patches for frameworks, libraries, and dependencies with known vulnerabilities
- Small feature additions implemented carefully within the existing architecture
- Dependency updates where possible, keeping libraries current within the constraints of the legacy stack
- Documentation of the system as we learn it, the tribal knowledge that was never written down
- Monitoring recommendations for early detection of problems in ageing infrastructure
- Honest assessment of when maintaining the system is no longer the right investment
For businesses that need this work on a continuing basis rather than a one-off, it usually runs through one of our support retainers.
Technologies We Use
Legacy support is technology-agnostic by necessity. We work with whatever the system was built in. Our core competencies cover:
- PHP (including older versions and frameworks: CodeIgniter, CakePHP, plain PHP)
- WordPress legacy sites and plugins
- MySQL / PostgreSQL database maintenance and optimisation
- JavaScript (jQuery-era codebases through to modern frameworks)
- Python legacy scripts and services
For technologies outside our direct experience, we assess during the audit phase and are transparent about whether we can support the system effectively.
Related Systems
Legacy systems often need to integrate with modern systems we build. A legacy order processing system might need to feed data into a new reporting dashboard. A legacy client database might need to connect to a new client portal. We build these integrations carefully, respecting the legacy system’s limitations while extending its useful life, and that connecting work is covered in more depth under system integration.
Talk to Us About Your Legacy System
If you have a system that needs to keep running and no one to maintain it, get in touch and we will assess the codebase and tell you honestly what it will take to support it, and whether you should.
Buying Time, Deliberately
Sometimes the right answer is not to modernise anything. The system works, replacing it is disruptive and expensive, and there are better uses for the money this year.
That is a legitimate position, and it is different from the position most businesses are actually in, which is the same outcome arrived at by avoidance. The difference is whether the risks are known and contained.
Support is what turns the second into the first: the system keeps running, somebody is watching it, and the things that would turn an inconvenience into a crisis have been dealt with.
What Has To Be True To Do This Safely
You can get the data out. If you cannot, that is the first job regardless of everything else, because until then every decision is made under duress.
Somebody can still change it. If the answer is nobody, the priority is capturing the knowledge while it is still recoverable, not keeping the lights on.
It is not reachable from the internet unnecessarily. Old software with an open administrative interface is the single most common way these systems get compromised.
Backups exist and have been restored from. Not whether the job runs.
Get those four right and an old system can run for years without being a liability. Miss them and you are not buying time, you are accumulating exposure.
What Support Actually Covers
Monitoring, so a failure is noticed by you rather than reported by a customer. Applying what patches remain available. Keeping the environment reproducible so the system can be rebuilt if the machine dies. Documenting what is known, continuously, because that knowledge is the thing most at risk. Fixing what breaks. And a bridge when something new needs to talk to it.
What it does not cover is making the system better. Support keeps it alive; that is the deal, and expecting improvement from a maintenance arrangement leads to disappointment on both sides.
The Line That Changes The Answer
When the vendor stops issuing security fixes.
Before that point, an old system is old. After it, every newly published flaw stays open permanently, and the exposure grows on a schedule set by other people.
That does not force immediate replacement, and it does change what support means: the system needs to be isolated more carefully, watched more closely, and the replacement conversation needs a date attached rather than a vague intention.
What Moves The Price
How reproducible the environment is. A system nobody can rebuild is expensive to support because every intervention is risky.
Whether documentation exists. If not, creating it is part of the work and it is the part that pays off most.
How exposed it is, and how much isolation work is needed.
Response expectations, particularly out of hours.
Questions To Ask Whoever Supports It
- Could you rebuild this from scratch if the server died? If not, that is the first piece of work.
- What is still receiving security updates, and what is not?
- What is reachable from the internet?
- When did we last restore from backup?
- What is documented, and what lives in somebody’s head?
A Brief You Can Send Anyone
The system: [what it does for the business]
What it runs on: [including “we are not certain”]
Who understands it: [names, or nobody]
What breaking would cost: [per hour or per day]
Whether we can export the data: [yes / no / never tried]
How long we intend to keep it: [honestly]
What is already going wrong:
How We Approach It
Establish the four conditions above first, because they decide whether support is buying time or postponing a problem. Then monitor, document, patch what can be patched, and isolate what cannot.
When the replacement conversation does arrive, legacy modernisation covers it, and the work done during support makes that project considerably cheaper because the system is finally understood.
Get in touch and we will start with whether you can get your data out.
