The COBOL skills gap is real, but it's only part of the story.
The bigger risk in most agencies is lost knowledge: what the system does, why it does it that way, and which rules are buried in the code. Teams that capture that knowledge before they change anything have a much better shot at modernizing without surprises.
This is the third post in our series on mainframe modernization. If you're new to the topic, start with Is COBOL Still Used? What Government Leaders Should Know About Mainframe Systems, and see Rehost, Refactor, or Rewrite: How to Choose a Mainframe Modernization Approach for the options on the table.
What is the COBOL skills gap?
It's the shrinking pool of people who can maintain systems written in COBOL and similar older languages. The Government Accountability Office (GAO) describes it plainly in its 2025 review of critical federal legacy systems. Agencies have had difficulty finding employees with COBOL knowledge, may need to pay a premium for specialized staff or contractors, and face significant mission risk when too few experts are available for a critical system.
The examples in that report are specific:
That last one matters. A skills shortage doesn't just make maintenance harder. It can slow down the planning meant to get an agency out of the situation.
Is the problem really the programming language?
Partly. But experienced people in this field often point to something else.
COBOL was designed to read in a plain, business-oriented way, and a developer who knows it can usually fix a small problem in a small program. The challenge comes with scale. As Government Technology reported in 2021, the real issue is institutional knowledge. When the people who wrote an application years ago leave, those who remain often don't know it as well. In the meantime, the system has typically grown, picking up new functions, new use cases, and new users. One expert quoted in the piece described the difficulty of working with millions of lines of code when nobody knows where to start looking.
The same article offers a useful reality check on workforce headlines. Surveys it cited suggested the average age of COBOL programmers hasn't moved dramatically over time, though it noted that total numbers are expected to decline. In other words, the "everyone is about to retire" story is often overstated, while the knowledge-loss problem is not.
Government leaders have seen this play out in public. In April 2020, New Jersey's governor said the state needed volunteers with COBOL skills to help its unemployment system handle a surge of pandemic claims. State spokespeople later suggested they had enough programmers. Either way, the episode showed how quickly a hidden dependency can become a public problem.
What does "undocumented code" mean?
It means the rules a system follows aren't written down anywhere except in the code itself, or in the heads of a few people. A few common signs:
- Business rules that grew over decades. Policies and regulations change, and the system gets updated to match. GAO notes that the Defense system above has gone through significant application changes over the years because of policy and regulation changes. Each change adds a layer.
- Documentation that no longer matches reality. Manuals and diagrams were accurate once, but nobody has updated them since the last dozen patches.
- Hidden connections. Batch jobs, file transfers, and interfaces to other systems that only a few people know exist.
- Special cases nobody remembers. The odd exception for a particular program, date range, or population that someone added years ago for a good reason.
This isn't unusual, and it isn't a sign of poor management. It's what long-lived systems look like. It becomes a problem when an agency tries to replace or move the system without first finding all of it. GAO's Treasury Inspector General reporting is a reminder that even basic visibility can be a challenge: in 2024, the IRS had no specific or long-term plans for 191 of 231 legacy systems it had identified as of April 2020.
What goes wrong when agencies skip the understanding step?
When a team doesn't capture what the old system really does, the new one tends to work for the common cases and fail on the unusual ones. A new payroll system might calculate standard pay correctly but mishandle a retroactive adjustment or a special pay category that the old system handled quietly for years. (This is just an example, not a real case.)
The consequences are typically schedule delays, rework, and testing that turns up surprises late, when they're most expensive to fix. It's one more reason the incremental, well-planned approach we described in the last post tends to hold up better.
How can teams recover and document what a legacy system knows?
The specifics depend on the system, but the overall flow is usually similar:
- Capture knowledge from people now. Interview and shadow the people who know the system. Record walkthroughs. Do it while those people are still available, not after they've retired.
- Analyze the code and data. Map programs, jobs, interfaces, and data flows to see how the pieces connect.
- Extract the business rules. Turn what the code does into plain-language rules, then have program and policy staff confirm them. This step is often called business rule extraction, and it's where the real understanding lives.
- Build a baseline for testing. Use real inputs and outputs from the existing system to establish what "correct" looks like, so any new system can be checked against it.
- Keep the documentation alive. The point isn't a binder that sits on a shelf. It's a living record that supports whichever modernization path comes next.
Where can AI help?
Quite a bit, with limits. AI tools can summarize unfamiliar code, trace dependencies, and draft plain-language explanations much faster than teams could by hand, which makes steps 2 and 3 more practical than they used to be. But the output is a starting point. Engineers and the people who know the program still need to verify it. We explain how that works in AI-Driven Legacy Modernization: The Discipline Behind the Orchestration.
Should agencies train their own people or bring in outside help?
Usually both. Cross-training current staff builds long-term resilience. Outside teams can add capacity and speed, and they can document the system as they go so the knowledge doesn't live with just one person or one vendor. What matters most is avoiding a single point of failure, whether that's one veteran developer or one contractor.
A few questions can help leaders gauge their exposure:
- Who are the two or three people who really understand this system, and what's the plan if they leave?
- Where do the business rules live today?
- When was the documentation last checked against how the system behaves?
- Could we explain to an auditor, in plain language, exactly what this system does?
If the answers are uncomfortable, that's useful information. It's far better to find out before a modernization effort starts.
At The Canton Group, we've worked on legacy systems for government and enterprise clients since 1998, we start by understanding the system mission behind it. Our in-house team approaches each environment its own terms, because no two are alike.
Frequently Asked Questions
Is there really a COBOL skills shortage?
Yes, in the sense that agencies report difficulty finding and keeping COBOL expertise and may pay a premium for it. Headline statistics about retirement are often overstated, but the loss of institutional knowledge is a genuine and well-documented risk.
The language was designed to be readable and business oriented. The harder part is learning a specific, decades-old system and the business rules inside it.
What is business rule extraction?
It's the process of identifying the rules a system follows, such as eligibility, calculations, and exceptions, and documenting them in plain language so they can be validated and carried into a modernized system.
What does undocumented code mean?
It refers to code whose behavior and purpose aren't captured in current, accurate documentation, so understanding it depends on reading the code or asking the people who know it.
Can AI replace COBOL programmers?
No. AI can speed up reading, summarizing, and translating legacy code, but experienced engineers and subject matter experts still need to verify the results.
How can an agency keep knowledge when experts retire?
Capture it early through interviews and recorded walkthroughs, document the business rules, build test baselines from real data, and cross-train multiple people so no one person holds all the knowledge.
Wondering how well your own legacy systems are understood? Contact The Canton Group. We're happy to talk through where you stand and what a practical first step looks like.
