A system nobody understands any more

An inheritance nobody asked for

The system arrived with the job, the acquisition or the reorganisation. It runs the orders, the bookings or the month-end, and has done for years. The person who wrote it left long ago, their successor has gone too, and the only documentation is a folder of screenshots from a training session. People use it every day and nobody would dare change it.

That caution is reasonable. Without knowing how a system works, any change is a guess. The answer is to find out how it works, and that is more achievable than it looks.

What is there to be found

A working system is its own record. Everything it does is written down somewhere on the server, in a form a developer can read:

• The code says what happens on each screen and in each calculation.
• The database schema shows what is stored and how records relate to each other.
• The scheduler lists the jobs that run when nobody is watching: the overnight import, the Friday invoice run, the email that goes to the warehouse at six.
• Configuration files name the other systems it talks to.
• Logs show which parts are used daily and which have not been touched in years.

That last point matters. Old systems carry dead weight: screens for a product line dropped long ago, a report nobody opens. Knowing what is unused shrinks the problem.

The gaps are usually in the reasons. Code shows that orders over a certain value are held for approval. It does not say who asked for that or whether it still applies. For those answers we talk to the people who use the system.

Why it is usually still maintainable

Undocumented does not mean badly built. Many of these systems are conventional applications on a mainstream platform, and a developer who knows that platform can find their way around. The work is slower at first because every assumption has to be checked. It speeds up as the documentation grows.

What makes a system hard to maintain is something else: missing source code, a platform nobody can build any more, or logic scattered so widely that no change stays contained. An investigation establishes which of these apply, if any.

Your options

Leave it alone. If the system works and needs no changes, doing nothing costs nothing today. The risk builds quietly: the server ages, the platform goes out of support, and the first failure arrives with nobody able to respond.

Investigate and document it. A period of structured investigation turns an unknown into a known. Your own IT staff or provider can do part of it: listing the servers, scheduled tasks and backups needs no programming. A code audit covers the rest and gives you a written report.

Replace it. Tempting, but a replacement must do what the old system does, and that is exactly what nobody knows. A replacement project that skips the investigation tends to discover the missing rules after it has gone live.

What we would do first

We would take a copy of everything and work on the copy. On it, we establish that the system can be built from its code, restored from a backup and released. Then we write down what we found.

Before changing any behaviour, we add automated tests around the parts that matter most, such as pricing, invoicing and permissions. The tests record what the system does today, so a later change that alters a result is caught before your customers see it.

From there the system can be taken over and maintained like any other, or modernised in stages if the investigation shows it needs it.