COBOL

The Reality

COBOL processes an estimated 95% of ATM transactions and 80% of in-person financial transactions worldwide. It handles insurance claims, pension calculations, tax processing, and benefits administration. These are not small systems running on forgotten hardware. They are enormous, battle-tested platforms processing millions of transactions daily with reliability that most modern architectures struggle to match.

The language itself is verbose but precise, and its batch processing capabilities remain genuinely impressive. A well-structured COBOL batch job running on a mainframe will process volumes of data that would require careful engineering to replicate in any modern stack. What makes these systems difficult is not the language’s ability to compute. The challenge is that the people who understand COBOL are retiring at a rate that outpaces new training, and the systems built in it are increasingly expected to participate in real-time, API-driven ecosystems they were never designed for.

The Risks of Doing Nothing

• The talent cliff is real and accelerating. The average COBOL developer is well past fifty. Universities stopped teaching it decades ago. Every year, your pool of people who can maintain these systems shrinks.
• Regulatory exposure grows. Auditors and regulators increasingly expect systems to produce data on demand, not in overnight batch cycles. COBOL systems that cannot respond to real-time reporting requirements create compliance risk.
• Attempted big-bang replacements fail. The history of large-scale COBOL replacement projects is littered with expensive failures. Doing nothing is risky, but doing everything at once is worse.

How We Approach This

We treat COBOL modernisation as a long-term programme, not a project. The first step is always understanding the system boundary: what goes in, what comes out, what the batch schedules look like, and where the business logic actually lives versus where it is just data marshalling.

The most effective pattern we have seen is building an API facade in front of existing COBOL programs. Using middleware or transaction gateways, COBOL programs can be invoked as services without changing a line of COBOL. This lets modern front-ends, mobile applications, and partner integrations consume COBOL business logic through standard REST or messaging interfaces. The mainframe stays, the COBOL stays, but the rest of the organisation can interact with it using modern protocols.

Where batch processing is the bottleneck, we look at whether specific batch jobs can be decomposed. Often a nightly batch run contains dozens of logically independent steps. Breaking these apart and triggering them on demand (or at least more frequently) can solve the real-time pressure without touching the core computation.

What You End Up With

• Existing COBOL business logic accessible via modern APIs
• Batch processing preserved where it works, decomposed where it creates bottlenecks
• Knowledge documentation capturing what tribal knowledge remains
• A realistic, phased roadmap for gradual migration of components where it makes sense
• Reduced organisational risk from single points of knowledge

What We Have Seen

We supported an insurance organisation that processed claims through a COBOL system running nightly batch jobs. Brokers needed claim status updates during the day, not the next morning. Rather than replacing the claims engine, we built an event-driven layer that captured state changes as the batch ran and exposed them through a lightweight API. Brokers got near-real-time visibility. The COBOL processing was untouched. The project took weeks, not the eighteen months a replacement would have required.

How Much Time Have You Actually Got?

Most people arrive at this page carrying a vague dread rather than a deadline. The useful thing is to turn that into a date. Work through these and you will know roughly where you stand.

You have years, not months, if: the system runs on supported hardware or a supported emulator, at least two people can confidently change the code, the batch window still fits comfortably inside the night, and nobody outside the organisation is asking for data faster than you can produce it.

You are inside two years if: one of your COBOL people has retirement in sight, the batch window has started to overrun on peak days, or a partner, regulator or acquirer has begun asking for API access rather than file drops.

You are inside twelve months if: exactly one person can safely change the code, and there is no written record of what the programs do. That is not a technology deadline, it is a human one, and it moves the day that person hands in their notice.

You have a hard deadline if: your mainframe or emulator has a published end-of-support date, or a hosting provider has given you a migration date. That date is your date. Everything else is negotiable; this is not.

What Breaks First

It is rarely the COBOL. In the order we usually see it:

1. Knowledge, when the person who understood a subsystem leaves and nobody can explain why a calculation is the way it is.
2. Integration, when a partner retires the file-transfer method you depend on, or requires an API you cannot expose.
3. Reporting, when someone needs a number during the day and the system can only produce it overnight.
4. Recruitment, when a vacancy stays open long enough that the work quietly stops happening.
5. The COBOL itself, last, and usually only when the platform underneath it moves.

Notice that four of the five are organisational. That is why replacing the code first is so often the wrong opening move.

Check These Six Things This Week

You do not need a supplier to answer any of these, and the answers will tell you more than a discovery project.

• How many people can change this system without supervision? If the answer is one, that is your most urgent problem and it has nothing to do with technology.
• When does the batch actually finish on your busiest day, not your average day? Track it for a fortnight.
• Is there a written description of what each major program does? Not code comments, but a description a non-COBOL developer could read.
• What is the published support end-date for the hardware, operating system or emulator underneath it?
• What does the outside world need from this system, and how does it get it today? List every file transfer, report and manual re-keying step.
• Which of those requests have got faster in the last two years? That trend line is your real pressure.

When You Genuinely Don’t Need To Act

If the system is stable, more than one person can maintain it, the batch window is comfortable, and nothing external is pulling for real-time data, then leaving it alone is a legitimate decision and probably the cheapest one available. COBOL is not a problem in itself. A system that works, that people understand, and that nobody is waiting on does not need a modernisation programme. We would rather say that than sell you one.

The trigger to revisit is not a birthday. It is any of the six answers above changing.

Ready to Talk About Your COBOL Systems

COBOL modernisation decisions carry real weight. These systems underpin critical operations, and getting the approach wrong is costly. A full rewrite is almost never the right answer, but neither is leaving things as they are indefinitely. We can help you find the incremental path that reduces risk without gambling on a replacement. Start a conversation.

For the risk management side of this kind of work, Risk Reduction in Legacy Transformation covers the frameworks we use to manage change on systems the business cannot afford to disrupt. Keeping Critical Legacy Software Alive is relevant if stabilisation is the right first step before any modernisation begins. And Incremental Modernisation explains the phased approach we use across all legacy programmes, including COBOL. The Legacy Systems Overview gives context on how these options fit together.