Every mainframe modernization proposal opens with the same lament: the documentation is gone. The analysts who wrote the system retired or died, the design docs were never updated past the first release, the change history lives in comment headers nobody trusts, and the only people who understand why a given COBOL paragraph does what it does are two people from operations who are also retiring next year. This is presented as the central risk of the project — an irrecoverable knowledge gap that justifies months of "discovery" before anyone writes a line of replacement code. It is a real problem. It is also, in the form it's usually sold, a myth, because it treats documentation as the only source of truth about what the system does, when the system itself is a far more reliable source than any document ever was.
Documentation describes intent at the moment it was written. A COBOL program compiled and running in production describes what actually happens, right now, on real inputs, including every edge case, every undocumented exception path, and every place where a business rule quietly diverged from whatever the original design doc said it should be. If the two disagree — and on a system old enough to have lost its documentation, they always disagree somewhere — the code is not the thing that's wrong. It's the thing that's been correctly executing payroll, claims, or settlement runs for thirty years while the document sat in a binder nobody opened. Treating "we lost the documentation" as a blocking crisis gets the priority backwards. The documentation was never going to be the specification for a byte-exact replacement. The running system already is one, and it doesn't need to be reconstructed from memory — it needs to be observed.
What "discovery" usually buys instead
The discovery phase that follows a "documentation is lost" finding is where a lot of modernization budgets quietly go missing. Weeks or months get spent interviewing the remaining staff who remember fragments, reverse-engineering flowcharts from source code by hand, and producing new documentation artifacts — decks, wikis, requirements matrices — that describe the vendor's current best understanding of the system. This work isn't worthless, but it's the wrong deliverable for the actual risk. A requirements matrix is a claim about the system. It still has to be checked against the system to know if it's true, and that check is exactly the parity work that should have started on day one instead of after a discovery phase that consumes runway and produces a document with the same trust problem as the one it replaced: it's someone's belief about behavior, not proof of it.
The honest version of discovery isn't interviews and flowcharts. It's building the harness that runs real production inputs — payroll batches, claim files, settlement transactions, whatever the system actually processes — through both the legacy system and the candidate replacement, and comparing outputs byte for byte. That harness answers the question documentation was always a proxy for: does the new thing do what the old thing does? A stack of design docs, current or lost, was never going to answer that question directly. Only execution and comparison can.
Why this reframing matters to a buyer
The practical consequence is about where risk actually lives in the schedule. If a vendor's plan treats "reconstruct the documentation" as a prerequisite phase before conversion can begin, that's months added to the timeline for an artifact that doesn't reduce the real risk — parity — at all. It reduces a different risk, the vendor's own comprehension of the system, which is a legitimate need but should be scoped and billed as such, not disguised as a project-wide blocker that has to be cleared before any verifiable progress can be shown. A buyer should expect comprehension to happen in parallel with, and validated by, parity work against production data from week one — not as a gate in front of it.
This also changes what a buyer should ask for as proof of progress. "We've documented 40% of the modules" is not evidence the project is on track; it's evidence someone wrote things down, with no way to know yet whether what they wrote down is correct. "We've achieved byte-exact parity on 40% of production transaction volume, reproducibly, against the last twelve months of real batches" is evidence, because it can only be true if the underlying behavior — the thing that actually matters — has been captured, whether or not anyone ever explained it in English. The system was the documentation the whole time. The only question worth billing for is whether someone has actually read it correctly, and the only way to prove that reading is correct is to run it and check.
The myth's function
None of this means lost documentation is a nothing-problem — comprehension still costs real time, and a system with genuinely undocumented edge cases is genuinely harder to reproduce than one with clean specs. The myth isn't that documentation loss is costless. The myth is the implied conclusion: that without it, correctness is unknowable until someone reconstructs a paper trail, and that reconstruction has to happen before verifiable work can start. It doesn't. It's a convenient framing for a vendor who would rather bill discovery time against an open-ended narrative of institutional memory loss than commit, early, to parity numbers a buyer can check. Ask what percentage of production transaction volume has been proven byte-exact this month, not this year. If a vendor can't answer that in month one because they're still "reconstructing documentation," they've told you which risk they're actually managing, and it isn't yours.