Preserving Knowledge Before Your Developers Retire

Part 3 established that lost institutional knowledge is a compounding risk on a human timeline. This part is about the timeline itself, the narrow window when the people who understand a system are still around to help preserve what they know, and what it takes to use that window well before it closes. For operators of business-critical legacy systems, this is often the single most time-sensitive decision in the entire modernization question.

The clock you don’t control

Most risks in software run on a schedule you can influence. This one doesn’t. The people who hold the deepest understanding of long-lived systems are leaving on a timeline set by their careers, not your roadmap.

The most-cited data point makes the shape clear: reported figures put the average COBOL developer’s age at roughly 58, with about 10% of that workforce retiring each year (IBM, reported via Fujitsu, 2020). You don’t need your systems to be on COBOL for the pattern to apply. The same dynamic holds for any stack old enough that its experts learned it decades ago and its newcomers aren’t learning it at all. On any specific system, the people who genuinely understand it are usually a small group, and that group’s remaining tenure is finite and shrinking.

The capturable window is the overlap between two things: the expert still being available, and you having started the capture. You control only the second. Every quarter of delay shortens the overlap, and unlike most schedule slips, this one can’t be recovered with overtime. Once the expert is gone, the cheapest and most reliable source of validation is gone with them.

Why the standard handover fails

The default response to a retiring expert is the knowledge-transfer handover: a series of meetings, some documents, maybe a recorded walkthrough, in the person’s last weeks. It feels responsible. It mostly doesn’t work, for reasons that have nothing to do with effort.

The core problem is that handover relies on recall, and recall doesn’t surface the knowledge that matters. The rules an expert holds aren’t sitting in a list ready to be read out. They’re indexed by situation. They come to mind when something triggers them. Ask “tell us everything important about this system” and you get the dozen things that happen to be top of mind. The rule about the one customer invoiced differently, the validation that exists because of a 2014 incident, the ordering constraint that only matters at quarter-end: those don’t come up, because nothing in a conference room triggers them. They’d have surfaced the next time the situation arose. There won’t be a next time.

The second problem is timing. Handover competes for the expert’s final weeks against every other demand: closing out their own work, the backlog, the actual day job. Knowledge transfer is the task with no hard deadline, so it loses to the tasks that do. The most valuable activity gets the least protected time, exactly when it’s irreplaceable.

The result is a handover that captures what the expert remembered to say and silently loses everything else, and the losses are invisible until someone hits one.

The inversion: recover first, then validate

The approach that works inverts the order. Instead of asking the expert to produce the knowledge from memory, you produce a draft from the code and ask the expert to correct it.

Reacting to a concrete draft is a fundamentally easier and more complete cognitive task than recalling from a blank page. Show an experienced engineer a written description of what a module actually does, its branches, its edge-case handling, its data effects, and the response is immediate and rich: “yes, but that case there is because of an incident, and this branch is dead, and you’ve missed the rule that only fires at month-end.” The draft acts as a trigger for exactly the situational knowledge that interviews can’t reach. The expert stops being a fallible narrator and becomes a reviewer, which is the role their experience actually makes them best at.

This is where AI-accelerated discovery earns its place. Reading an entire legacy codebase end to end to draft what it does, the call graph, the data flows, the edge cases, the undocumented rules, is precisely the slow, comprehension-heavy work that teams run out of people and time to do by hand. Done as an AI deep-read, the analysis that took twelve weeks of manual review takes about two, roughly 10× faster as an analysis-time gain, and it produces the draft specs the experts then validate. The honest framing matters. The AI doesn’t know the rules, it proposes them from evidence in the code, and a senior engineer plus the original author decide what’s right. Recovery from the code, validation from the people, each doing what it’s actually good at.

What the expert uniquely provides

Pairing code-recovery with the expert isn’t a way to extract them faster and move on. It’s a division of labor along the line of what each source can actually answer.

Question	Best source
What does this code do?	The code (recovered as a draft spec)
Does this draft match reality under load?	Production behavior / parity validation
Why does it do it?	The expert, and often only the expert
Is this rule load-bearing or dead?	The expert, confirming against the draft

The code can tell you what happens. What it usually can’t tell you is why: the incident, the regulation, the customer commitment behind a rule that otherwise looks arbitrary. That “why” is the part that lives almost exclusively in the expert’s head, and it’s the part that determines whether a future team treats a rule as sacred or safely removes it. Capturing the why, against a concrete draft, while the person is still here to give it, is the highest-value hour in the whole exercise.

What is actually worth capturing

“Preserve the knowledge” is too vague to act on, and teams that treat it as one undifferentiated task usually capture the easy parts and miss the load-bearing ones. It helps to name the distinct kinds of knowledge, because each lives in a different place and is recovered a different way. Not all of it comes from the expert, and knowing which parts do is how you spend their remaining hours well.

Knowledge type	Where it actually lives	How you recover it
What the code does: branches, edge cases, data effects	The code	AI-accelerated deep read drafts it as a spec
Why a rule exists: the incident, regulation, or customer behind it	Almost only in the expert’s head	Expert annotates the why against the concrete draft
Integration contracts and downstream side effects	The code plus the teams on the other end	Trace call sites, then confirm intent with downstream owners
Data quirks and dirty-data workarounds	The data itself, explained by the expert	Profile the real data, expert explains the exceptions
Operational runbook: the manual step, what breaks at 2am	Ops tribal memory, rarely written down	Interview tied to the specific code path, capture as a runbook

The pattern is that the code carries the what and the expert carries the why and the operational lore. A capture plan that spends the expert’s scarce time confirming things the code already states is spending it in the wrong place. Point their hours at the rows the code cannot answer.

Running the capture before the window closes

The mechanics matter as much as the intent, because the failure mode is not “we didn’t try” but “we tried the way that loses the important parts.” A capture that works tends to follow the same shape.

1. Start from a draft, never a blank page. Hand the expert a recovered spec of the module and ask them to correct it. Do not open with “tell us everything about this system.” The draft is what triggers the situational memory an open question never reaches.
2. Prioritize by business criticality, not code volume. Rank modules by what breaks the business if it goes wrong, and capture those first. The largest file is rarely the most dangerous one.
3. Protect the hours. Knowledge capture has no hard deadline, so it loses to work that does. Carve out protected, recurring time on the expert’s calendar and defend it, because the alternative is that it never happens until the last rushed week.
4. Record the why, not just the confirmation. When the expert says a rule is right, ask why it exists. A confirmed rule with no reason attached still leaves the next team unable to decide whether it is safe to change.
5. Produce a reviewed artifact, not a meeting transcript. The output is a corrected, annotated spec the team owns, not a recording nobody rewatches. If it is not written down as a living spec, it was not captured.
6. Name what could not be confirmed. Where the expert is unsure, flag it as open risk rather than papering over it. An honest list of unknowns is worth more than false completeness, because it tells parity validation where to look hardest.

What if the expert has already left?

Sometimes the window is already closed. The person who understood the system retired last year, or the team that built it was reorganized away. This is worse, but it is not hopeless, and it is the strongest argument for starting the capture on every other system now rather than later.

When the expert is gone, you lose the cheapest and most reliable validator, but the evidence they left behind is still there to be read. The code remains the source of truth for what the system does. Automated tests, where they exist, encode intent someone once thought worth protecting. Version-control history and commit messages sometimes carry the why that never made it into a document. Issue trackers record the incidents that produced the strange rules. Production data reveals the exceptions the code quietly handles. AI-accelerated discovery can assemble all of this into a draft far faster than a new team could by hand, and a senior engineer can reason about it.

Be honest about what is lost, though. Without the original author, some rules will stay ambiguous. You will not always know whether a branch is a deliberate safeguard or an accident nobody dared touch. Those gaps do not get resolved by staring harder at the code. They get resolved the same way every recovered behavior does, by proving it against the running system slice by slice. Which is the point of the next section.

What capture doesn’t replace

Capturing knowledge before people retire is necessary, but it is not the same as proving you got it right, and it would be dishonest to suggest the two are equivalent. A validated spec is a far better artifact than a handover transcript, but it’s still a model of the system, and models have gaps. The expert can confirm what they recognize. Neither they nor the AI can guarantee that nothing was missed. That’s why capture is the first half of the discipline and not the whole of it. The captured behavior still has to be proven against the running system slice by slice, through parity validation, before anyone bets production on it. Knowledge capture closes the window-driven risk. It doesn’t replace the evidence. Treating a reviewed spec as proof would just be a more sophisticated version of “trust us.”

Where this leads

This part argued for recovering behavior from the code and validating it with the people who remain. That raises a concrete question. How do you actually pull a business rule, not just a code path, but a rule the business runs on, out of a legacy codebase? Part 5, Capturing Business Rules from Legacy Code, gets specific about what that recovery looks like and why the code, not memory, becomes the source of truth.