The COBOL Developer Cliff Is Not an IT Problem: It Is a Board Problem

Somewhere in your organization, a handful of people understand how your most important systems actually work. As experienced COBOL developers leave the workforce, fewer new developers are entering the field, in part because the language is no longer widely taught in universities. As a result, the institutional knowledge required to maintain these systems is becoming increasingly scarce. That creates more than a staffing challenge. It creates an operational and strategic risk that leadership needs to understand and plan for.

This final blog of our three-part series exploring the business realities of COBOL modernization will discuss the shrinking pool of COBOL talent and retirement risk. Click to catch up on building the business case for change and the missing piece in COBOL modernization solutions, independent oversight.

The Growing Risk of the COBOL Developer Talent Cliff

This is the COBOL cliff, and it is easy to file under “IT will handle it.” That would be a mistake. The exposure it creates is strategic, and it belongs on the risk register the board actually reads.

Start with the concentration risk. When the institutional knowledge of a core banking, claims or benefits system lives in the heads of a few people who are all approaching retirement at once, you do not have a staffing issue. You have a single point of failure wearing a human face. The systems were often built without complete documentation, so when those people leave, they take with them the only real understanding of why the code does what it does. In many cases, that knowledge extends beyond maintenance to the nuances of decades-old COBOL coding practices that are rarely documented anywhere else. New Jersey discovered this exact scenario in public during the pandemic, when its unemployment system buckled and the state could not find experienced COBOL developers who knew how to fix it.

From a Project Management Office (PMO) perspective, this risk is often compounded by the absence of formal knowledge-transfer plans, succession strategies and documentation programs intended to preserve critical system expertise before it leaves the organization.

How Legacy Systems Limit Growth and Innovation

Now layer on where the organization is trying to go. Boards across industries are pushing an AI and data agenda. Those ambitions run on data, and in most legacy shops, the data is trapped in decades-old COBOL systems that modern tools cannot easily access or integrate with. You cannot run advanced analytics, and you certainly cannot deploy AI using data you cannot access cleanly. The legacy core that feels like a back-office concern turns out to be the thing quietly capping your growth strategy.

The Security, Compliance and Resilience Exposure

And then there is resilience. These systems run on hardware and software that vendors increasingly do not support. Unsupported means unpatched, and unpatched means an expanding security and continuity exposure on the exact systems that process your transactions and hold your customers’ data. In a regulated industry, that is not just an operational worry but an examination finding waiting to happen.

These concerns underscore the need for formal program risk management practices that identify, monitor, and mitigate technology, compliance and operational risks before they become business disruptions.

Put all these pieces together, and it becomes clear that continuing to keep COBOL up and running is not just a maintenance line item. Staying on COBOL is a convergence of talent risk, strategic risk and operational risk, all pointing at the same aging foundation. That is board territory.

Reframing COBOL Modernization for the Board

The reason it stays mislabeled as an IT problem is that it usually reaches the board as one. A technical team asks for a large sum to modernize something the board does not fully understand, framed in language the board does not fully speak. The request gets deferred, because “the system still works” is an easy thing to believe right up until the moment it does not.

The fix is to reframe the decision in the board’s own terms. What is our actual exposure, quantified across talent, security, compliance, and resilience? What does inaction cost us, not just in maintenance but in strategic optionality? What is the cost and the return of acting, and over what horizon? Those questions turn a vague technical anxiety into a governed decision an executive team can own.

This is the project management work we do before anyone touches the code. Through PMO-led assessments, governance structures, risk management frameworks and executive stakeholder alignment, organizations can make informed modernization decisions long before a migration begins. We quantify the risk of the current state in terms a board recognizes. We build the financial case for change. And when the organization commits, we provide the independent governance that keeps the program honest all the way to the finish. We are not the ones performing the migration, which is precisely why you can trust our independent assessment of the risks and the program.

What’s Next

The last generation of COBOL developers who understand your core systems is already heading for the door. The question that your board needs to answer is not simply whether to preserve aging technology but how long the organization can continue relying on specialized COBOL coding expertise that is becoming increasingly difficult to replace. If you want that exposure quantified and framed for your board, that is exactly where Withum comes in.