How to Audit an Undocumented Codebase

An audit should start the same way a takeover does: confirm who has the authority to review the code, and get it running in an environment that is isolated from whatever is currently in production. Reviewing code by reading it alone misses a lot; running it, even with dummy data, reveals behaviour that static reading cannot — which features actually work, which throw silent errors, and which pieces of the interface lead nowhere.

Imagine a manufacturer that inherited a decade-old shop-floor scheduling tool, originally built in-house by an engineer who has since retired. Before anyone reviews a single line of that tool's code, the sensible first step is standing up a copy on a separate machine or staging server, using a snapshot of real, anonymised data, so the audit can poke at the running system without any risk to the production schedule the shop floor depends on every day.

With a running copy available, map what the application is actually built on: the language and framework versions in use, every third-party library it depends on, and each entry point — web routes, scheduled jobs, background workers, any place execution begins. Undocumented systems frequently accumulate entry points no one remembers exists, like a forgotten scheduled task that still runs nightly.

This mapping does not need special tooling to start — dependency manifests, a directory listing of the codebase, and a look at what scheduled jobs the server runs will surface most of it quickly. What this step produces is the skeleton the rest of the audit hangs off: a list of what exists before judging whether it is any good.

Data flow is usually the least documented part of any inherited system, and the most important to reconstruct: where does data enter, where is it stored, what transforms it along the way, and where does it leave — to a report, an export, another system. Tracing this by following the code, or by watching database queries while using the running copy, is slower than reading a diagram, but it is often the only option available.

Alongside data flow, reconstruct how the application is actually built and deployed: what commands turn source code into a running application, what the deployment process looks like, and whether that process is documented anywhere or exists only as tribal knowledge in whoever last touched the server. An audit that stops at the code and never establishes how deployment works leaves the most operationally risky gap unexamined.

Once the shape of the system is clear, assess it for risk: known vulnerabilities in outdated dependencies, hardcoded credentials sitting in the code, and any component that depends on a technology past its own vendor's support window. Test coverage, or its absence, is a separate but related signal: a codebase with no automated tests is not necessarily broken, but every future change to it carries more risk than a change to a codebase where tests exist to catch a mistake.

Maintainability is the final piece: how consistent is the code style, how tangled are the dependencies between modules, and how much of the system would a new developer need to understand before making a safe change. None of these need a precise score — a rough high, medium or low rating against each area is usually enough to inform what comes next.

The audit's real output is not a pile of findings — it is a system map a non-original developer can actually use: the framework and dependency list, the entry points, the data flows, and the deployment process, written down in one place for the first time. Alongside it, a remediation backlog, ranked by risk and business impact, turns the findings into a plan rather than a list of complaints.

This map and backlog become the reference document for every future decision about the system — whether to repair, modernise or rebuild it, how urgently, and in what order — replacing whatever tribal knowledge the system previously depended on.