From Hidden Knowledge to Executable Tests: A Practical Modernization Path

The single most undervalued activity in enterprise modernization is moving knowledge out of people’s heads and into something a machine can run. Not specifications. Not slides. Tests.

Why this matters more than it sounds

Every long-lived enterprise system contains a large amount of behaviour that no document describes. Some of it is on purpose, some of it is accidental, all of it is real. The people who know it tend to be a small number of long-tenured engineers — and the modernization programme is precisely the moment when those engineers are most likely to leave or be reassigned.

If that knowledge does not move into executable form before they go, the modernization programme has to reverse-engineer it under pressure. That is the most expensive way to do this work.

What “executable knowledge” looks like

We are deliberately not talking about exhaustive unit tests. We are talking about a small number of high-value tests that pin down the behaviour that matters:

• Characterization tests that capture the current behaviour of a critical workflow, regardless of whether the current behaviour is “right”.
• Contract tests at integration boundaries, describing what consumers actually rely on.
• Scenario tests that walk through end-to-end business cases the team would refuse to break.
• Database behaviour tests for stored procedures, jobs, and triggers carrying business logic.

The bar is not “this code is well tested”. The bar is “if you change the system in a way that breaks this behaviour, a machine tells you”.

How to capture it in practice

Three habits work:

1. Pair the senior engineer with a writer. Every conversation about “how this actually works” ends with a new failing-then-passing test, not a paragraph in a wiki.
2. Start with the workflows the business cannot lose. Order capture, invoice generation, payment posting, partner sync. The list is usually short.
3. Let the AI draft, let the human commit. Agentic AI is well-suited to drafting characterization tests once the workflow is described. A senior engineer reviews, adjusts, and commits. The test is a deliverable in its own right.

The compounding effect

Once a critical workflow has executable tests, three things become possible:

• The workflow can be refactored without fear.
• The workflow can be migrated to a new runtime with confidence.
• The workflow’s behaviour survives the eventual departure of the people who originally knew it.

That is the actual return on this work. Not coverage percentage. Continuity.

The honest summary

Modernization programmes that invest early in turning hidden knowledge into executable tests move faster, lose less behaviour, and survive personnel changes. Programmes that postpone this work in favour of “we’ll write tests as we go” almost always run out of time, ship surprises, and damage trust. The order matters.