The COBOL on your mainframe is not a relic. It runs the ledger, the policy engine, the overnight batch the whole company depends on. We modernize it one slice at a time — COBOL, mainframe DB2, and JCL read together, parity proven against the mainframe before any cutover.
Estimates of how much COBOL still runs in production range from roughly 220 billion lines (Reuters, 2015, via IEEE Spectrum) to upper-bound figures near 800 billion (Micro Focus) — present it as a range, because nobody has counted it precisely, and the honest answer is that there is a lot of it. It carries core banking, insurance, payroll, and government systems that have been correct for forty years. The code is not the problem. The problem is the people. The COBOL workforce is aging — the average mainframe programmer is around 58, and on the order of 10% retire each year (IBM, via Fujitsu) — and the graduates entering the field are not lining up to learn a stack they see as having no future. The risk is not that the COBOL stops working. It is that the people who understand it leave faster than they can be replaced.
For a COBOL/CICS/DB2/JCL estate the target is concrete: business logic re-expressed as Java or C#/.NET services, VSAM and DB2 data moved onto a modern data platform, and the batch and CICS transaction flows surfaced as clean APIs. Which language, which cloud, which data platform — that is chosen with you in Discovery, not dictated by the source, and it can land in a regulated or air-gapped environment. What we hold constant is the shape of a system built to last.
A slice is a single behavior — one batch job, one online transaction. Each is analyzed, rebuilt, validated in shadow against the mainframe, and promoted only on parity. A strangler facade shifts traffic gradually; the COBOL retires last.