The COBOL Cliff: Modernising Mission-Critical Systems When the Expertise Is Retiring

"The system works. It hasn't had unscheduled downtime in years. The last organisation that tried a full replacement spent three years and abandoned it. And the two people who actually understand the settlement logic are both over sixty."

That is roughly what you hear when you ask a bank CTO why they have not modernised their core system. Notice that only one clause of it is a technical answer, and it is not the one that should worry you.

The risk is not that it breaks

Legacy systems get discussed as though the danger is failure. It generally is not. Mainframe estates running COBOL are among the most reliable computing systems ever built. They have run continuously through decades of change, and they do what they do extremely well.

The risk is that you cannot change it fast enough when you have to.

Regulatory change arrives with a deadline. A new product needs a field the core system does not have. A partnership requires an integration the architecture never anticipated. A central bank mandates a reporting format. In each case the question is not whether the system works. It is how long a change takes and how many people can make it.

When the answer to the second question is two, and both are approaching retirement, you no longer have a technology estate. You have a succession problem with a technology estate attached to it.

Why the expertise problem is worse than a staffing problem

If this were simply a hiring issue it would be expensive but manageable. It is not, for a reason that takes a moment to see properly.

A COBOL system that has run a bank for thirty years does not just contain code. It contains thirty years of accumulated decisions. A branch that exists because of a regulatory change in 2004. An exception handling a product that was discontinued but whose accounts still exist. A rounding rule that looks wrong and is not, because it implements a specific interpretation of a specific requirement agreed with a regulator two decades ago.

None of that is in the documentation, because documentation was never the point. The code was the specification. The reasoning lived in the heads of the people who wrote it, and it transferred by apprenticeship rather than by being written down.

That is why replacement projects fail at the rate they do. Not because writing new code is hard. Because you cannot rewrite what you cannot specify, and the specification does not exist anywhere except inside a system nobody fully understands and inside a shrinking number of people.

The numbers around this circulate widely and vary considerably by source, which is itself part of why boards struggle to act on it. Better established is the Futurum Group's mainframe skills research, which found 91 per cent of organisations expecting to hire mainframe administrators or application developers within one to two years, while 62 per cent cited a lack of modern mainframe skills as their most significant hiring barrier. The hardest people to find are not COBOL developers. They are mid-career professionals who understand both the legacy system and modern architecture.

The market has responded the way markets do. Institutions rehire retired engineers as contractors at rates that make modernisation look cheap by comparison, which is a reasonable short-term strategy and not a plan.

Why this became urgent in the UAE

There is no reliable public data on the scale of legacy estates in Gulf banking, insurance, government and telecommunications, and I am not going to invent any. What is verifiable is the demand side, and the demand side has changed dramatically in the last twelve months.

In April 2026 the UAE Cabinet approved a programme to transform fifty per cent of federal government sectors, services and operations into agentic AI models within two years. By June, fifty federal entities were on a ninety-day sprint, each required to take an agentic service from selection through to implementation planning. In Abu Dhabi, the Government Digital Strategy commits around AED 13 billion toward becoming what the Department of Government Enablement calls the world's first fully AI-native government by 2027, with over a hundred AI use cases already deployed across more than forty entities.

Here is what lands on engineering leadership.

You cannot make a 1990s core system agentic.

An AI agent that resolves a citizen request end to end needs to read state, take actions and confirm outcomes across the systems that actually hold the data. If those systems expose no APIs, if their business logic is embedded in batch processes nobody has traced, if a change requires a three-month release cycle and the only person who can specify it is unavailable, the agentic ambition stops at the integration layer.

Modernisation has quietly stopped being an infrastructure programme and become the constraint on the AI strategy. That reframing matters commercially, because "replace the core system" and "unblock the AI programme the board has already funded" compete for very different budgets.

The talent picture compounds it. Regional ICT skills shortages are well documented, the UAE hires a large proportion of technology professionals from abroad, and Emiratisation targets in banking intensify competition for the same people. The pool of engineers who understand both a legacy estate and modern architecture is small everywhere and smaller here.

What has actually changed

For twenty years the options were bad in predictable ways.

Maintain meant accepting slower change and a worsening succession problem. Rewrite meant a multi-year programme with a poor success record, because of the specification problem above. Wrap meant putting APIs around the legacy system, which bought integration without addressing the underlying dependency and frequently added a layer nobody understood either.

What has changed in the last two years is not the rewriting. It is the reading.

AI systems can now analyse large legacy codebases and explain what they do. Trace a transaction through thousands of lines of COBOL or RPG. Identify which branches are live and which have been dead for a decade. Surface the business rules embedded in the logic. Generate the documentation that was never written, from the only authoritative source, which is the code itself.

That addresses the actual bottleneck. Not the effort of writing new code, which was always the manageable part. The comprehension of the old.

The practical consequence is that a modernisation programme can begin with something it could rarely begin with before: an accurate specification of what the current system does, produced in weeks rather than through the slow archaeology of interviewing people who are leaving.

It also changes who can do the work. A capable engineer who does not know COBOL can work productively on a COBOL estate when the system can explain the code to them. That does not eliminate the need for deep expertise. It changes how much of it you need and what you need it for, which for an organisation with two remaining experts is the difference between a viable programme and an impossible one.

Where IBM Bob fits

IBM Bob is an agentic development platform built for this class of work, reaching general availability in April 2026. Rather than completing individual lines of code, it plans, executes and validates multi-step development and modernisation tasks across a codebase.

What makes it relevant here is its premium modernisation packages for IBM Z, covering COBOL and PL/I, IBM i, covering RPG, and Java. Those are the three estates that describe most of the legacy footprint in regional banking, insurance, government and telecoms.

Two of its properties matter more than the productivity story.

It produces an auditable record. Its command layer creates self-documenting logs of agent actions, and human approval checkpoints are configurable. For a regulated institution, a modernisation programme that cannot evidence what changed and who authorised it creates a different problem while solving this one.

And security scanning runs at authoring time rather than as a later gate.

On the productivity figures: IBM reports an average 45 per cent gain across its own developer population, with case studies claiming substantially larger compressions on specific tasks. Those are IBM-reported, internally measured, and derived largely from IBM developers working on IBM systems. Treat them as directionally interesting rather than as a forecast for your estate, because the variable that determines your outcome is the condition of your codebase, not the tool.

IBM is not alone in this space and the category is moving quickly. The reason to look at Bob specifically for a Z, i or Java estate is the modernisation packages, which encode IBM's own experience of those platforms into repeatable workflows.

The question this creates

There is a governance problem sitting immediately behind all of this, and engineering leaders in regulated institutions will meet it fast.

If an AI system analyses your core banking code, proposes changes and generates replacements, who reviewed it? Under what authority was the change authorised? Can you produce that evidence in eighteen months when an auditor asks how a particular calculation came to be written the way it is?

Regulated industries require documented change control. That requirement does not relax because the change was proposed by a machine, and the volume of change an agentic tool can produce puts pressure on review processes designed for human output.

There is also a code quality dimension worth taking seriously rather than dismissing. Independent research on AI-generated code has found meaningful rates of security weakness across models and languages, with Java performing notably poorly in at least one large study. That is not an argument against the approach. It is an argument for authoring-time scanning, human review gates on material changes and proper testing, which is exactly what the tooling in this category is being built to support.

How to actually start

The failure mode is to treat this as a replacement programme. Framing it that way is how you end up asking a board for three years and a large number.

Start with comprehension, not code. Take one bounded, material area of the estate and produce an accurate specification of what it currently does. This is the step that was previously impossible at reasonable cost and is now the cheapest part. It also produces something valuable regardless of what you decide next, because you will own documentation of a system that had none.

Fix the succession risk before the architecture risk. Your immediate exposure is not that the system is old. It is that knowledge is leaving. Extracting what the system does while the people who understand it are still available is the highest-return activity on this list, and its value does not depend on any subsequent modernisation decision.

Modernise against a business constraint, not a technology one. "Migrate off the mainframe" is not a business case. "Expose the eleven capabilities our agentic service programme needs, with a change cycle measured in days" is one, and it will be funded, because it attaches to a commitment the organisation has already made.

Set the change governance before the volume arrives. Agree what review an AI-generated change requires, which categories need human sign-off, what evidence gets retained, and who owns the decision. Doing this before throughput increases is considerably easier than retrofitting it afterwards.

Keep your experts on judgement, not typing. The two people who understand the settlement logic should be reviewing specifications and adjudicating edge cases, not reading code an AI could read for them. That is also, incidentally, how you keep them.

The window

The generation that built these systems is leaving, and the trajectory is not in dispute even where the figures are.

The organisations that come through this well will not be the ones that started earliest or spent most. They will be the ones that recognised the actual constraint. Not the code, which was always tractable. The understanding of it, which was not, and which is now.

The window for extracting that understanding while the people who hold it are still reachable is closing at a known rate. That is a narrower and more urgent problem than modernisation, and it is the one worth starting on this quarter.

DISCLAIMER - This article describes the regulatory landscape as understood at the date of publication and is provided for general information. It does not constitute legal advice. Organisations should obtain advice from qualified UAE counsel on their specific circumstances.