COBOL isn't dead. The devs who maintained it, yes.

The 2025 METI report is unequivocal: 85% of large Japanese companies run their critical systems on COBOL or IBM Z mainframes. The average age of developers able to maintain them is 58. The window is closing. It's called the "2025 cliff", and it's here, now.

The classic integrator response: "we'll give you Copilot, you'll be fine". No. Copilot writes decent Python. It doesn't migrate thirty years of COBOL/CICS/DB2 technical debt to cloud-native without breaking prod. Here's our approach.

Why a standalone LLM is not enough

An average COBOL banking program is 200,000 to 800,000 lines, with nested PERFORMs, chained COPYs, CICS calls, hardcoded DB2 access, and business logic that depends on the exact order of fields in copybooks. Feed that to GPT-4 or Claude in chat mode: it will read 8,000 lines, lose context, and make up the rest. That's exactly what happens in 90% of PoCs we're asked to take over.

Our approach: the three Abbeal agents

We apply to COBOL the same multi-agent methodology as on Java or .NET legacy (see our legacy modernization article). Three specialized agents, each with its tools, guardrails, and human owner.

1. The Archaeologist: parses COBOL with a dedicated AST (proleap-cobol-parser), rebuilds the call graph, identifies real business rules via static analysis + execution on real production traces.
2. The Architect: proposes a Java 21 or Kotlin target on Spring Boot, with a bounded-contexts migration plan, and the interop strategy during transition (often via existing MQ Series).
3. The Cleaner: generates target code in modules of 2,000 to 5,000 lines, with equivalence tests replaying captured production inputs.

The big bang trap

Migrating everything at once is suicide. Our method: strangler fig pattern. We wrap existing COBOL behind internal REST APIs (via z/OS Connect or a Java JNI wrapper), then progressively replace each endpoint with a cloud-native implementation. The mainframe dies in slices, with no service interruption.

java
// Strangler facade : le client appelle l'API moderne,
// le routeur décide si la requête va vers le legacy ou la nouvelle impl
@RestController
public class CustomerController {
    @Autowired private CobolGateway legacy;
    @Autowired private CustomerServiceV2 modern;
    @Autowired private FeatureFlag flags;
    
    @GetMapping("/customers/{id}")
    public Customer get(@PathVariable String id) {
        if (flags.isEnabled("customer-v2", id)) {
            return modern.findById(id);
        }
        return legacy.callCobolModule("CUSTGET", id);
    }
}

The human factor

Existing COBOL teams are not a problem to liquidate, they are irreplaceable sources of business knowledge. Our process systematically includes pairing sessions between senior COBOL developers and our cloud-native engineers. The AI agents capture and formalize that knowledge, which would otherwise have vanished.

The results on our COBOL projects

• Migration time reduction: 70 to 85% vs. manual rewrite.
• Captured behavioral coverage: > 92% via equivalence tests on production traces.
• Total cost: generally divided by four over the project duration.
• Regression risk: -60% vs. classic big bang approach.

The 2025 cliff is not an abstract threat. If you run COBOL, you know exactly how many months you have left before your last expert retires. Our Franco-Japanese teams have dual expertise in legacy COBOL and modern cloud-native. The time to talk is now, not eighteen months from now.