Home/Services/Legacy software maintenance
Legacy software maintenance
Maintenance is routine right up to the moment the people who built the system move on. After that, every defect is an investigation. We take over long-lived applications and keep them running while the business carries on depending on them.
The usual starting point
It happens gradually. One developer leaves, then another. The person who understood the billing logic changes role. A release goes badly and the team quietly becomes more cautious. None of it shows up as a decision anywhere.
What eventually shows up is a support queue that stops moving, and a system everybody depends on but nobody wants to open.
Scope
Most of it is unglamorous and none of it is optional. The point is that the system stays available and the queue keeps moving.
The work that has a deadline attached whether anyone planned for it or not.
The work that decides how expensive the next twelve months will be.
Method
The first weeks decide whether maintenance becomes cheaper or more expensive over time. This is the part most handovers skip.
Reproduce the reported behaviour, trace it through the code and the database, and find out what the system is really doing. A fix written before that stage is a guess with a commit message.
Most legacy systems fail silently. Adding logging and error reporting where it is missing means the next incident starts with evidence instead of speculation — and it is usually the cheapest change available.
Small, reversible changes released regularly, rather than a large batch every few months. Risk comes from the size of a release far more than from the age of the code.
Maintenance is not the opposite of progress. The same understanding that makes a defect quick to fix is what makes incremental modernization possible later.
Questions
That is the normal case rather than the exception. The code and the database are the specification, and reading them is part of the work.
A few hours with anyone who still remembers the domain shortens the ramp-up considerably, but it is not a precondition.
No. Most systems we are asked about are ones whose original developers have already left — that is usually why the conversation starts.
What helps far more is access to the running system, a build that works, and someone on the business side who can explain what the software is supposed to do.
No. Maintenance and modernization are separate decisions, and conflating them is how budgets disappear.
If a rewrite is genuinely the cheaper option we will say so. But a working system that has become expensive to change is usually a refactoring problem, not a replacement problem.
Either a framework agreement with an agreed monthly capacity, or per-incident work against a defined scope. An NDA is signed on request before we see any code.
Next step
Describe it in a few sentences — what it does, what technology it runs on, and what is currently going wrong. That is enough for a useful first answer.
