How to audit the legacy system everyone is afraid to touch

Every established company has one: the system that runs something critical, that nobody fully understands, and that appears in every architecture diagram as a gray box labeled with a nervous asterisk. The instinct is to avoid touching it until forced. The discipline is to audit it before the forcing event arrives — because the forcing event chooses its own timing, and it never chooses well.

Here's the assessment we run in two weeks, in the order we run it.

Days 1–3: interview the humans before the code

The most valuable documentation for a legacy system is in the heads of the two or three people who operate it, and they are usually closer to retirement than anyone wants to calculate. We start with structured interviews: what breaks, what the workarounds are, what the system must never be asked to do, and what the 6 a.m. batch job actually produces. One hour with the operator who has babysat the system for fifteen years is worth a week of code reading — and unlike the code, that knowledge has a departure date.

Days 4–7: map what it touches, not just what it is

Legacy risk is mostly connective. The VB6 application is scary; the forty undocumented things that consume its database directly are the actual blast radius. We trace every inbound and outbound dependency — file drops, database reads from other systems, scheduled jobs, the Excel macro in accounting that everyone forgot — because the migration plan is really a dependency retirement plan. Systems with three consumers migrate in months. Systems with forty migrate in phases, and knowing which you have changes every downstream decision.

Days 8–11: characterization tests around the crown jewels

You cannot safely change what you cannot verify. For the system's most critical behaviors — the billing calculation, the eligibility rule, the settlement file format — we write characterization tests: capture real inputs, record current outputs, and pin that behavior down regardless of whether anyone remembers why it works that way. The behavior is the specification now. These tests become the safety net for every future change, and writing them always surfaces at least one 'wait, it does what?' that justifies the whole exercise.

Days 12–14: rank the risk, pick the safe first move

The output is not a rewrite proposal. It's a risk-ranked map: which components are stable and can be left alone, which are fragile and load-bearing, and which single move — usually a facade API or the extraction of one well-bounded capability — retires the most risk for the least surgery. The best first move is almost always smaller than stakeholders expect and more valuable than it looks. Modernization is won by sequences of safe moves, not by courage.