Before Replacing COBOL, Preserve the System Intent

When people hear COBOL today, many imagine an old programming language, green screens, mainframes, banks, and systems that should have been replaced long ago. But the more I think about it, the more I believe that COBOL itself is often not the biggest problem.

Yes, the syntax is old. Yes, the environment may feel unfamiliar to modern developers. Yes, someone used to contemporary frameworks may feel as if they are looking into the past. But in critical financial and enterprise systems, the most important question is usually not:

How quickly can we replace COBOL with something more modern?

The more important question is:

Do we truly understand what the system does?

That is where the real value of legacy systems begins — and also where the real risk of modernization starts.

Old Code Often Contains Old Decisions

In modern software, we like clean documentation, automated tests, architecture diagrams, issue tracking, and well-defined APIs. In older systems, reality is often different. Part of the knowledge is in the code. Part of it is in reports. Part of it is in batch jobs. Part of it is in database tables. Part of it is in operational procedures. And part of it is simply in the heads of the people who have maintained the system for years.

A rule may have been introduced twenty years ago because of a specific regulation. A workaround may not be removable because it compensates for a historical data exception. A report may look strange, but accounting may have relied on it for years as a control point. A batch job may run in a specific order for a reason nobody wrote down.

Then a modernization programme arrives with a simple goal:

Rewrite it in Java, .NET, the cloud, or a modern database.

Technically, that may sound reasonable. But if the organization loses the reason why the old system behaved the way it did, it may replace the syntax and lose the meaning.

Financial Systems Are Not Verified Just Because They Run

In financial systems, it is not enough for the new application to start successfully, respond through an API, and show a green deployment status. The key question is whether it produces the same result — or a different result that is fully understood and approved.

In accounting, banking, insurance, and batch-processing environments, the critical details often include:

  • control totals
  • balances
  • reconciliations
  • month-end and year-end closing
  • accounting periods
  • corrective documents
  • exceptions
  • reversals
  • rounding
  • VAT or tax calculations
  • exchange rates
  • due dates
  • historical business rules
  • audit and regulatory reports

If an old COBOL program produced a report that accountants used for twenty years, the modernization question is not only:

Did the new system generate a similar report?

The better questions are:

Does the report reconcile where it must reconcile?
Can we explain every difference?
Is a difference a bug, or a correction of old behaviour?
Who approved the new result as correct?

This is why legacy modernization is not only a programming task. It is also an accounting, analytical, process, and knowledge-management task.

A COBOL Programmer Is Often Not Only a Programmer

In an ideal world, every system would be perfectly documented. In practice, an experienced legacy programmer often carries knowledge that documentation does not contain. They know which job must not be executed twice. They know why a file is sorted before it is processed. They know which errors are serious and which are historical noise. They know why a specific account is handled differently. They know which report the accounting department checks after closing. They know what happens when a batch fails halfway through.

This is tacit system knowledge. And it can be as important as the source code itself. If such a person retires or leaves the company, the organization may not only lose a programmer. It may lose part of the system’s memory.

Modernization Without Knowledge Is Guesswork

Many modernization projects start with a technical sentence:

We will replace the old system with a new one.

But before that, there should be a set of more boring, but much more important questions:

  • What does the system actually do?
  • Which outputs are critical?
  • Which rules are legal or regulatory?
  • Which rules are historical exceptions?
  • Which reports are used daily?
  • Which reports are needed for audit?
  • Which batch jobs must run in a fixed order?
  • Where are the control points?
  • How are error states handled?
  • Who can explain the difference between expected and actual output?

If these answers do not exist, modernization becomes a risky rewrite. The new system may be more elegant, more scalable, and easier to deploy, but it may still be wrong from the business point of view.

Tests Should Start Before the Rewrite

For legacy systems, I would not start with the question:

What technology should we rewrite it in?

I would start with:

How will we prove that the new system does the right thing?

That means creating behavioural tests before the major change. Not only unit tests in the modern development sense, but tests that reflect the old system’s business behaviour:

  • input batch
  • expected output
  • control total
  • report
  • error log
  • state before processing
  • state after processing
  • and explanation of differences

For financial systems, reference scenarios should include:

  • a normal month
  • month-end closing
  • year-end closing
  • corrective documents
  • zero values
  • rounding
  • reversals
  • invalid input
  • repeated execution
  • batch failure halfway through
  • migration of old data

Without such tests, modernization is trust. With them, modernization becomes a controlled process.

Documentation Is Not Enough If It Does Not Capture Why

People often say that old systems need documentation. I agree, but documenting only the structure is not enough. It is not enough to write:

This program reads file A and writes file B.

The more important questions are:

Why is file A processed before file B?
Why is this account excluded from the summary?
Why is the amount rounded in exactly this way?
Why does the batch stop on this error instead of continuing?
Why is this report sent to a specific department?

Modernization needs documentation of what the system does. But it also needs documentation of why it does it. And that “why” is often held by experienced people rather than by documents.

Where AI and LLMs Can Help

The current wave of AI may help legacy systems — but only if used carefully. An LLM can help summarize old code, search across documents, explain parts of a program, prepare maps of business rules, and support the creation of test scenarios. But in critical financial systems, I would never rely only on a fluent answer from a model.

The point is not whether the answer sounds good. The point is whether it has evidence. For legacy systems, AI should operate inside a controlled knowledge system:

  • with approved sources
  • with citations
  • with access controls
  • with document versions
  • with links to code
  • with links to test scenarios
  • with clear uncertainty signals
  • and with human approval where risk requires it

AI can be a useful layer above legacy knowledge. It should not replace understanding of the system.

Sometimes the Right Answer Is Not to Rewrite Everything

Modernization does not always have to mean a big rewrite. There are several possible paths:

  • keep the core and improve documentation
  • create tests around existing behaviour
  • wrap the old system with an API layer
  • migrate only part of the functionality
  • refactor high-risk components
  • separate reporting
  • gradually replace batch processing
  • or keep the system but monitor and document it better

Sometimes the most reasonable first step is to admit that the old system may be technically unattractive but still business-critical. In that case, the goal does not have to be:

Get rid of COBOL.

A better goal may be:

Reduce the risk of depending on an old system and on the few people who still understand it.

That is a much more precise description of the problem.

What I Would Do Before Modernizing a Legacy System

If I had to prepare a sensible modernization path, I would start with these steps.

  1. Map the Critical Processes
    Not all programs have the same importance. The first step is to identify:

    • which batches are critical
    • which reports must reconcile
    • which tables are the source of truth
    • which processes affect accounting
    • which outputs are regulated or audited

  2. Capture Knowledge from People
    Interviews with experienced people should not be the last step before they leave. They should be part of modernization preparation. The questions should include:

    • what must not be changed
    • what is not in the documentation
    • where errors most often occur
    • which exceptions are historical
    • which reports are actually used
    • and what is still checked manually

  3. Create Reference Scenarios
    Before changing the implementation, there should be a set of inputs and expected outputs. Not only clean ideal data, but also dirty, historical, and edge-case data. Those cases reveal whether the new system preserved the meaning of the old one.

  4. Create an Evidence Chain
    Every change should have a visible link:

    old behaviour -> new behaviour -> difference -> explanation -> approval

    Without that chain, trust in the new system is difficult.

  5. Decide What Really Needs to Change
    Only then does it make sense to decide whether the system should be:

    • refactored
    • rewritten
    • replaced
    • integrated
    • or kept and documented better

COBOL as a Reminder of Something Important

For me, COBOL is interesting today not because old technologies are better. They are often heavy, uncomfortable, and difficult for new people to enter. But they remind us of something important:

Software is not only code.

Software is captured organizational decision-making. In critical financial systems, code may contain the history of processes, exceptions, regulations, data corrections, accounting rules, and operational compromises. If modernization changes only the technology and does not preserve the meaning, the result may be a more modern system that the organization understands even less.

Conclusion

COBOL is not just syntax. It is an entry point into a world where software has carried financial processes, batches, reports, controls, and decisions for decades. If we talk about modernizing legacy systems, we should not begin with:

Rewrite COBOL.

We should begin with:

Understand what the system does, why it does it, and how we will prove that the new system preserves the correct outcomes.

Only then does it make sense to talk about technology. Whether the result is refactoring, an API layer, partial migration, a new system, or keeping the existing core, modernization should begin with understanding. Not assumption.

The greatest value of a legacy system often does not live only in its source code. It lives in its meaning.