A business-critical system that has run for fifteen or twenty years tends to outlive the people who built it. The original developers retire or move on. The documentation, if it ever existed, drifts out of date or was never written in the first place. What remains is a system everyone depends on and almost no one fully understands — its knowledge concentrated in one or two long-serving staff, or, increasingly, in no one at all. The organisation runs on something it can no longer explain, and most of the time that is invisible. It stops being invisible the moment something has to change.
It is tempting to file this under housekeeping — documentation that ought to be tidied up eventually. It is more serious than that. A system understood by one or two people is a continuity risk: if they leave, capability leaves with them. It is a brake on change, because you cannot safely modify what you do not understand, so even small adjustments become slow and risky. And in regulated industries it is a governance gap, because an auditor will reasonably ask how an organisation controls a critical system it cannot describe. The missing knowledge is not an inconvenience; it is exposure.
The usual response — ask the remaining experts to write it all down — rarely works. It captures only what they consciously remember, which is a fraction of what the system does, and it omits the things that have become automatic and therefore invisible to them. It competes with their day job and stalls. And it cannot account for the parts of the system no living person remembers building. A documentation effort built on human recollection inherits the exact weakness it is meant to fix: it knows only what people know, and the problem is precisely that people no longer know.
There is a more reliable source, and it has been there all along: the system itself. An analysis built on AI can ingest the FMB source files, the database schema, whatever documentation exists, historical support tickets and test cases, and add an agent that explores the live application and records how it genuinely behaves. From that evidence it reconstructs what the system actually does — not what anyone remembers it doing. The absence of documentation, the norm in legacy Forms environments, stops being a barrier, because the answers are read from the system rather than recalled from memory.
The live exploration is what reaches the parts memory cannot. An agent running against the working system can follow every screen, trace which code paths actually execute under real use, and capture the navigation patterns that have become so habitual no one would think to describe them. Set against the source files and the database schema, this builds a picture of the system as it truly behaves today — not as a decade-old document claims it should, and not as the people still around half-recall it.
The output is the map the organisation never had: a structured specification of the system’s behaviour, a dependency graph showing how modules and data connect, a clear view of which screens are actively used and which lie dormant, and a record of where the business rules actually live. This is the principle behind tools built for the purpose — understand the legacy system before you change it. For the first time, the knowledge that lived in people’s heads, or had vanished entirely, exists in a form the organisation can read, question and rely on.
Because the map is drawn from the system, it belongs to the organisation rather than to individuals, and it keeps its value long after any single expert has gone. That alone reduces key-person risk immediately — before any migration is even decided. In regulated environments it doubles as audit-ready documentation of a system that previously had none, produced under appropriate controls. The recovered knowledge is not a means to an end you must commit to today; it is an asset in its own right, useful whether you migrate next year or not at all.
Once you can see the system clearly, every subsequent decision gets easier and safer. Maintaining it becomes less fragile, because changes can be made with knowledge of what they affect. Modernising or migrating becomes a matter of evidence rather than guesswork, with a real scope and a real risk picture. The point of recovering the knowledge is not only to feel safer; it is that clarity is the foundation for whatever you choose to do next, and you cannot make a good decision about a system you cannot see.
That is why the recovery is worth doing regardless of what follows. If the decision is to keep the system running for now, you have removed the single-person dependency that made it fragile. If the decision is to modernise or migrate, you have the scope and the risk picture that every successful project rests on. The same few days of analysis serve all three futures, which is rare for any piece of work: it is useful whether you act on it immediately or simply keep it against the day you need it.
Next step. Recovering it takes a few days of analysis, and it is worth doing for its own sake — before it is forced on you by a departure, an audit, or a change you can no longer make safely.
