Every modernization pitch eventually reaches for the same line: "you can't find COBOL people anymore, so you'd better move off it — or pay us to keep it running." The frustrating thing about this pitch is that it starts from something true. It just doesn't end there.
The real problem
The core system at a bank, an insurer, or a state agency was usually built by people who are now retired, retiring, or gone. Computer science curricula stopped teaching COBOL as a first language decades ago; nobody starts a career hoping to write it. The people who still understand a given estate deeply — not the syntax, the syntax is the easy part, but the accumulated forty years of business rules, workarounds, and "don't touch that field, we're not sure why" — are a shrinking, aging population. The U.S. Government Accountability Office has flagged this exact risk in federal agencies for years: legacy systems running on languages and skills the agency itself has trouble sourcing internally. That part of the story is not exaggerated. It is one of the more honestly documented risks in this entire industry.
So the scarcity is real. The question is what you're supposed to do about it, and that's where the pitch quietly swaps products on you.
The swap
Notice what the scarcity argument gets used to sell. Rarely is it "let's reduce your dependence on a handful of irreplaceable people." Far more often it's one of two things:
- An indefinite staffing retainer. A small bench of increasingly expensive contractors becomes the only people who can safely touch the system, and the arrangement never has an end date, because ending it would mean someone else has to learn what they know — and nobody wrote it down.
- A modernization built on the same tribal knowledge, unverified. The "accelerator" ingests the code, a small team interprets what it does from memory and interviews, and the target system is only as correct as those interviews were complete. Since the point of the exercise is that nobody fully remembers, this is a strange place to stop checking your work.
Both paths monetize the same fact: knowledge of the system lives in a small number of heads instead of in something you can independently verify. A vendor with an interest in staying indispensable has no reason to fix that, and every reason to keep reminding you how few people could ever replace them.
Scarcity of people is not scarcity of proof
Here is the distinction the pitch wants you to miss: the scarce resource isn't COBOL knowledge in the abstract, it's COBOL knowledge that has never been separated from the individuals who hold it. Those are different problems with different fixes.
If your only record of what the payroll batch job actually does is "ask Dave, he's been here since the AS/400 install," you have a knowledge-custody problem, and the honest fix is to make the system's behavior provable independent of Dave — a byte-exact record of inputs and outputs across the real edge cases, that anyone can rerun and confirm without needing Dave's memory to be perfect on a Tuesday. That is boring, unglamorous work. It is also the only version of "de-risking the scarcity" that actually reduces risk, instead of just moving the dependency onto a vendor's retainer instead of Dave.
Compare that to what "AI will read your legacy code and figure out what it does" is actually offering: a different kind of guesswork standing in for Dave's guesswork, except this one can't be cross-examined and produces a different answer if you ask it twice. That doesn't resolve the scarcity — it launders it. You have gone from "we're not sure, ask Dave" to "we're not sure, ask a model," and only one of those two can be handed a deposition.
What actually reduces the premium
A few things shrink the scarcity tax for real, and none of them are exotic:
- Behavioral capture before anyone leaves. Run the current system against a representative slice of real, production-shaped inputs and record the outputs now, while the people who can sanity-check them are still around. That record outlives any individual's employment.
- Determinism over interpretation. A deterministic translation of the code is checkable by anyone who can run a diff. An interpretation — human or AI — is only checkable by someone who already knows the right answer, which is exactly the scarce resource you're trying to route around.
- Escrowed, ownable output. If the target system, the test harness, and the parity evidence all belong to you in hand, the next scarce COBOL expert you can't find stops being a single point of failure, because the system no longer depends on anyone's unwritten memory to be understood.
- Stop pricing maintenance as a hostage negotiation. A retainer priced honestly for keeping a stable system running is reasonable. A retainer priced because "we are the only ones who understand it and we intend to stay that way" is a business model, not a service.
Ask the question that exposes which one you're buying
Next time a vendor invokes the scarcity story, ask them directly:
"If your two lead engineers left tomorrow, could a third party independently verify that the modernized system still matches production behavior — without asking either of them a single question?"A vendor who has actually solved the knowledge-custody problem will have a reproducible answer ready, because they built one for themselves first. A vendor who is selling you their scarcity as leverage will change the subject to how experienced their team is. Listen for which answer you get — it tells you whether you're buying a system, or a relationship with Dave's replacement.