Service · Software development

Replacing a Cobol system.

A COBOL application on the mainframe that has run your core processes for decades: batch processing, financial administration, policy administration, payroll or government benefits. The system still runs reliably, but the people who understand its logic are retiring, licence and capacity costs on the mainframe keep rising, and connecting it to a modern API or cloud environment is barely feasible with the current architecture. We expose and replace COBOL mainframe systems step by step, preserving the underlying business rules and validating extensively against the existing batch processing.

Arrange an introductory call See our work
↻

Shutting down a Cobol mainframe affects the heart of the business.

In banks, insurers, pension funds and government bodies, core processing often still runs on Cobol. Overnight batch jobs update policies, calculate salaries or process benefits, driven by JCL, with data in VSAM files or DB2 tables set up thirty or forty years ago. These systems are not fragile in the sense that they often crash; quite the opposite, they have proven over decades to run reliably under mission-critical load. That is precisely why they are so hard to let go of, and why replacing them demands such care.

Cobol is one of the stacks we encounter most often within our broader legacy software replacement work, but the mainframe context brings its own risks that call for a dedicated approach. The field is ageing, few new Cobol developers are entering it, and the people who still know the logic are often already retired or about to leave. Documentation is rarely available, or was written decades ago and never updated. As a result, every change to the system is riskier than it should be: nobody knows exactly what is happening under the bonnet.

The risk of not replacing the system is not that it collapses tomorrow. The risk is gradual: knowledge quietly disappearing with each retirement, licence and capacity costs claiming a growing share of the IT budget year on year, and an ever-widening gap with the modern APIs and cloud services the rest of the organisation now uses. That is why we always start by understanding what is in place, before deciding how and at what pace it will be replaced.

How we approach Cobol projects.

Documenting business rules
We reconstruct the batch logic and data sources before building anything
Phased decommissioning
Strangler pattern: migrating batch job by batch job while the mainframe keeps running
Parallel running and validation
Shadow runs alongside the existing batch, with comparison at record level
Capturing knowledge
What lives in the heads of departing Cobol programmers gets committed to paper

Three steps to replace a Cobol system.

On mainframe projects we rarely opt for a single intervention. The steps below follow one another and partly overlap: understanding what is in place, phasing it out gradually, and thoroughly proving that the new application calculates the same as the old one.

Approach 01

Documenting business rules and batch logic

The foundation of every Cobol project

We reverse-engineer the existing system: we audit Cobol programs and copybooks, follow the JCL to see the order in which batch steps run and depend on one another, and analyse the underlying VSAM files and DB2 tables for structure, keys and implicit relationships. Where colleagues who know the day-to-day workings are still around, we capture their knowledge before they retire or leave. The result is a readable catalogue of business rules that does not depend on any single person.

This phase is deliberately thorough, because the most common mistake in Cobol replacement is that a seemingly simple batch job turns out to contain a silent exception rule that was never written down. We would rather uncover those exceptions during discovery than only after a cut-over.

Copybook analysisJCL reviewVSAM/DB2 analysisKey user interviewsBusiness rules catalogueBatch schema mapping
Approach 02

Phased decommissioning using the strangler pattern

The usual route for business-critical mainframes

We set up an interface to the mainframe that allows batch streams and transactions to be redirected module by module to the new application once it is ready. The mainframe keeps running for as long as unreplaced batch jobs remain, and is emptied out module by module. For situations where part of the landscape will remain alongside a new layer for the time being, this ties in with our broader legacy software modernisation service.

In practice, this means core processing runs partly on the mainframe and partly on the new platform for several months, with no single moment when everything switches over at once. That feels slower than a big-bang cutover, but for financially critical systems it is almost always the safer and, in the end, faster route.

Mainframe interfaceBatch job by batch jobAPI layerFeature parity firstPhased rolloutAnti-corruption layer
Approach 03

Parallel running and record-level validation

Essential for financially critical processing

New modules are first built for functional equivalence with the existing system, not for improvement. Once a module is ready, it runs as a shadow run alongside the existing batch: the same input, two systems, and a comparison of outcomes at record level, from balances to control totals to key fields. Only when a batch matches exactly across several consecutive cycles is it considered ready for cut-over.

As this often involves financial administration, policies or benefit payments, we deliberately scope this validation process more broadly than for an average application. A discrepancy that might be acceptable in an internal tool is not acceptable here.

Shadow runRecord-level reconciliationFinancial validationRollback pathParallel batch comparisonCut-over plan

What you have at the end.

A modern system in production, documented business rules no longer held in the heads of a handful of people, and a mainframe that has been emptied out step by step.

Production + staging

Two environments on a modern, supported stack, either in your own cloud or on-premise.

Documented business rules

Readable documentation of what the COBOL logic did, independent of individual knowledge.

Data migration report

What has moved from VSAM and DB2 to the new database, and which validations were carried out.

Mainframe decommissioning plan

How the mainframe batch is emptied out batch by batch and ultimately switched off, with a read-only archive.

Managed service (optional)

Monitoring, backups, security patches and ongoing development under a maintenance contract.

When a COBOL modernisation project becomes unavoidable.

Four patterns where postponing is no longer the safe choice, and where we are usually first invited to a discovery meeting before anything concrete is planned.

Skills

The last COBOL programmers are retiring

The field is ageing and very few new COBOL developers are being trained. The people who truly understand the logic of your system are often the same people who will leave within the foreseeable future. Once that knowledge departs, every change to the system becomes a risky search rather than a routine task.

Cost

Mainframe licence and capacity costs are rising

Mainframe processing is usually charged according to usage and capacity, and those costs keep rising while the system's functionality stays the same. For organisations scrutinising their IT budgets, this eventually becomes a recurring discussion point with nothing new to show for it.

Integration

COBOL is difficult to connect to APIs and the cloud

A mainframe's batch-oriented architecture was not built for real-time integrations. Customers, partners and internal departments now expect direct APIs and cloud integrations. Every new connection to the old system requires a detour via file exports, intermediate layers or overnight batch processing.

Documentation

Nobody knows exactly what the system does any more

After decades of successive changes by different teams, the original documentation is outdated or entirely absent. Changes are postponed because nobody can say with certainty what a modification will affect elsewhere. That is precisely the point at which the risk of doing nothing outweighs the risk of replacing the system.

Risks we address explicitly.

A COBOL replacement is not a technical project; it is a change that affects financially critical processes. Four risk categories that sit at the top of every project.

Skills

Business rules disappear with departing staff

We begin every project with discovery and interviews, precisely before the last people who still understand the logic leave. We record what they know in a rules catalogue, so that knowledge does not depend on a single person or team.

Data

Errors in migrating VSAM and DB2 data

Legacy data structures often contain implicit relationships, invalid characters and exceptions that the mainframe always tolerated. We carry out a data audit beforehand and build a validation suite that compares every migration against the original, down to record level.

Continuity

Disruption to business-critical batch processing

We phase every transition so that one batch job or module moves over at a time, run extensive shadow runs before the cut-over, and keep a rollback path open until a sub-process has run stably over several cycles.

Compliance

Financial and insurance data subject to retention obligations

For data subject to a legal retention obligation, we maintain a documented, read-only archive of the legacy system and record the migration itself with an audit trail, so that traceability is never lost.

How a COBOL project runs.

01Introduction→ 02Discovery & documentation→ 03Build & parallel running→ 04Cut-over & decommissioning
Step 01

Introduction

Which system is in place, how old it is, who still understands the logic, which pain point is most acute. A no-obligation conversation with IT and the business.

Step 02

Discovery & documentation

We reverse-engineer the COBOL code, JCL and data structures, interview key users, and record the business rules in a rules catalogue.

Step 03

Build & parallel running

We build modules in sprints aimed at functional equivalence, run shadow runs alongside the existing batch, and validate every module at record level.

Step 04

Cut-over & decommissioning

Phased transition per batch job, rollback path ready, emptying and finally switching off the mainframe, with a read-only archive.

From COBOL mainframe to modern stack.

Some organisations run an AS/400 environment alongside their COBOL mainframe; for that combination we have a separate approach under AS/400 replacement. And because the batch output of COBOL systems is in practice often exposed through an outdated reporting layer, this project regularly also involves Crystal Reports replacement.

Mainframe stack we encounter
CobolJCLCICSIMSVSAMDB2PL/IAssemblerRACF
Target stack, frontend & backend
Java.NET 8PythonNode.jsReactPostgreSQLKafkaREST/GraphQL
Migration, infrastructure & integration
Strangler routingETL pipelinesBatch-to-eventAnti-corruption layerAWS/Azure/GCPTerraformDocker

Frequently asked questions.

How are business rules preserved when no documentation of the COBOL system exists?
We reconstruct the business rules from the code itself, rather than from documentation that is often missing or sparse. We read the Cobol programmes and copybooks, trace the JCL to see the order in which batch steps run, analyse the VSAM and DB2 structures to establish which fields and references really matter, and interview the staff who still understand day-to-day operations. We record what emerges in a readable rules catalogue. Where the code itself is ambiguous, we set up a shadow run in which the new system processes the same input as the mainframe, so that discrepancies become visible before any cut-over takes place.
Can we run the mainframe in parallel with the new system?
Yes, that is almost always the chosen route in COBOL projects. We set up a mainframe interface so that batch processing and transactions can be redirected module by module to the new application once it demonstrably performs on a par. The mainframe keeps running for as long as unreplaced components remain, and is only switched off once the last batch job has been taken over. That way there is never a moment when all core processing switches over in one go.
What happens to the data in the VSAM files and DB2 tables?
We begin with a data audit: which files and tables exist, which fields are still in use, and which references between VSAM files and DB2 tables are implicitly handled in the code rather than captured in a key. On that basis, we build a migration path to a modern relational or distributed database, supported by a validation suite that compares each migration stage against the original on record counts, totals and key fields. We keep the mainframe archive available in read-only form well beyond the cut-over, including for data subject to a statutory retention obligation.
How long does the discovery phase take before building begins?
That depends on how many Cobol programmes, copybooks, JCL jobs and data structures there are, and on how much knowledge is still held by the people who use or maintain the system. For a compact, reasonably well-documented system, discovery is a shorter phase; for an extensive mainframe landscape with decades of successive changes, reconstructing the logic takes more sprints. We only provide a concrete schedule once discovery is complete, because any estimate before then would be guesswork.
Is the risk of batch processing downtime during the project manageable?
Manageable, provided the work is phased rather than switched over all at once. Batch jobs are transferred one by one, and only after the new version has run stably for several cycles with identical outcomes alongside the existing processing. The greatest risk is not the switchover itself, but a side effect nobody anticipated. That is why we run extensive shadow runs and keep a rollback path open until a sub-process has demonstrably proven reliable.
Will you work together with the last Cobol programmers within our organisation?
Very much so, and wherever possible from the discovery phase onward. They know exceptions and workarounds that are written down nowhere and would otherwise only surface after the cut-over. We plan their involvement so that it does not become a full-time burden alongside their regular work, and we record what they know in documentation so that this knowledge does not disappear when they retire. If no one internal is still available, we reconstruct the logic entirely from code, data and interviews with the user groups who work with it daily.
How can we be certain that the new application calculates financially correctly?
Through extensive validation before any cut-over takes place. New modules are first tested for functional equivalence with the existing system, not for improvements. We then run shadow runs in which the same input passes through both the mainframe and the new application, and we compare the outcomes at record level: amounts, balances, control totals and key fields. Only when a batch or module matches exactly across several cycles is it considered ready for cut-over. For financially critical processing, we deliberately make this validation process more extensive than for an average legacy project.
Should we replace the entire mainframe in one go?
No, and we would advise against it. Replacing a full COBOL mainframe in one go is rarely justifiable for business-critical processing. We almost always opt for the strangler pattern: batch job by batch job, module by module, each is migrated once it is ready and validated, while the rest of the mainframe continues to run as normal. This stretches the project out over phases, but considerably reduces risk compared with a big-bang changeover.

Talk to us about your COBOL system.

A no-obligation introductory conversation of half an hour. We listen to what is running now, who still understands the logic, where the pain points are and what has prompted you to look at it now, even if it turns out that replacement is not the right route at this time.

Schedule an introductory callEmail fabian.vandijk@appfront.nl

Edit content