What is the software your business runs on actually doing — and who besides you knows?

If the honest answer is "the person who built it, and they're gone", you are not alone, and you are not helpless. A surprising share of established businesses runs some critical process — quoting, dispatch, billing, stock — on software whose original developer or vendor has left, gone quiet, or quotes prices that smell like hostage-taking. The instinct is to live in fear of it or commission an expensive rewrite. There is a third path, older and more ordinary than it sounds: understand the system first, properly, and then decide what it deserves.

The archaeology of inherited systems

Inherited systems share a recognisable archaeology:

  • Documentation that lies. Not maliciously — it was true once, and then the code moved on. Documentation unmaintained alongside the system is worse than none, because it is confidently wrong.
  • Databases nobody has a map of. The data holds the business's history and rules, but the relationships, the odd columns, the tables that must never be touched — all of it lives in someone's memory, or nowhere.
  • Integrations held together by memory. The system talks to other systems through interfaces only one person has ever seen. The integration is not the code; it is the recollection of the code.

The result is a business-critical asset that cannot be safely changed, integrated or supervised — not because it is bad, but because it is unknown.

Reverse engineering is everyday engineering

The legitimate answer is a practice engineers call reverse engineering, and it is more mundane than the movies suggest: reading what a system actually does from its observable behaviour — its database, its interfaces, its logs, its outputs — until the system's real behaviour can be documented, maintained, integrated or replaced. One boundary matters and should be stated plainly: this work applies to systems you own or have explicit permission to assess, for maintenance, interoperability and understanding — never to bypassing licences, cracking protections, or examining third-party systems you have no right to touch.

Done properly, the work produces what the business has been missing: a map. What the system does, in business terms. Which parts are load-bearing and which are dead weight. Where the data lives and what it means. The map is not an academic exercise; it is the difference between negotiating with knowledge and negotiating blind.

The AI assist — with the caveat stated

A genuinely useful new tool in this work is the large language model. Unfamiliar code paths can be explained, summarised and cross-referenced at a speed no human team can match; logs that would take days to read can be digested into "what this system was doing on a normal Tuesday". The caveat must be stated as firmly as the benefit: the AI's explanation is a hypothesis, not gospel. It is a senior engineer's job to confirm each explanation against evidence — the database, the behaviour, the test — before it enters the map. Used this way, AI compresses the archaeology from months to weeks. Used carelessly, it writes confident fiction into the only document you have.

Illustrative example: a manufacturing firm runs production scheduling on an application built a decade ago by a developer who retired last year. The replacement vendor quotes for a rebuild; the internal team cannot say which processes touch the database. The firm commissions a rescue instead: read-only observation of the running system, a map of the database built from evidence, the interfaces documented, and AI-assisted analysis of the codebase to accelerate the parts a senior engineer then verifies by hand. Within weeks the firm has what it never had: a truthful map. Two of the five integrations the old developer remembered were already dead; one undocumented nightly process was quietly load-bearing. The rebuild discussion changes entirely — now priced against knowledge — and the immediate maintenance risk is handled without one.

Why this makes oversight possible

The connection to oversight is direct: you cannot measure what you cannot see. An external vendor can tell you almost anything about an unknown system — that it is healthy, that a failure was unavoidable, that a quote is fair — and you have no way to check. The rescue work is what ends that asymmetry. Once the system is mapped, telemetry can be attached, evidence reports produced, and an independent reviewer can actually review. Handing a system to a vendor without that map is not outsourcing; it is delegation to whoever claims to know, and the rescue is what lets you verify what you are told.

Constraints and trade-offs

Three honest limits:

  • Some systems resist full understanding. Budgets are real, and a complete map of a decade-old system may not be worth its cost. Map the critical paths first — the parts whose failure stops the business — and let the dead corners stay dim until they matter.
  • The map is a living document. A rescue map that is not maintained decays exactly like the documentation it replaced. Budget the upkeep, or the archaeology starts again in three years.
  • Replacement is sometimes still the answer. Understanding does not oblige you to keep the system. It does something better: it lets the replace-versus-maintain decision be made on evidence, at the right time, priced against reality rather than fear.

Your action checklist

  • Name the system nobody understands, and what it would cost you per week if it stopped.
  • Check what documentation exists — and test it against the system's actual behaviour.
  • Map the critical paths first: the processes whose failure stops the business.
  • Use AI-assisted analysis for speed, and a senior engineer's verification for truth.
  • Attach telemetry to the mapped system so the map stays honest.
  • Revisit the replace-versus-maintain question with the map in hand.

If you are living with a system nobody understands, our platform modernisation service performs exactly this rescue: evidence-based mapping, AI-assisted analysis with senior verification, and the documentation that makes the system yours again. Once it is mapped, keep it honest with technical oversight — independent review against evidence — and reporting, analytics and monitoring so the map never goes dark.