COBOL to Java was the wrong modernisation.

01 / COBOL to Java was the wrong modernisation

Why COBOL endured.

COBOL survived for fifty years because of what it is underneath: compiled, native code that runs close to the machine. There is no application server to patch, no virtual machine to upgrade, no runtime whose support window sets the clock. Decimal arithmetic is exact, so a ledger balances to the penny. Batch jobs are scheduled, run and reconciled the same way every night.

The code is usually correct. It encodes decades of decisions about limits, rounding, dates, exceptions and approvals that nobody wrote down anywhere else. That is the asset. The hardware, the licences and the shrinking pool of people who can read it are the cost.

02 / COBOL to Java was the wrong modernisation

What the conversions did.

The 2000s answer was to convert or rewrite the core into Java, usually onto a Java EE application server. The conversions preserved the rules, more or less, and traded the mainframe for a runtime: a JVM with its own version cadence, a server with its own licence, frameworks with their own end-of-life dates, and a start-up time measured in minutes rather than milliseconds.

Converted code is often COBOL in Java clothing: the same procedural shape, the same copybook data structures, now wrapped in objects, running slower and consuming more memory than the original. It is harder to read than either idiomatic COBOL or idiomatic Java, which is why the people who can maintain it are also getting scarce.

03 / COBOL to Java was the wrong modernisation

The Java estate is the next legacy.

Application servers that were current when the conversion was signed off are past vendor support. JVM upgrades are postponed because something, somewhere, depends on the old behaviour. Licence renewals arrive with price rises that assume you cannot leave. The estate has become exactly what it was built to escape: a system that works, that nobody can fully explain, and that costs more each year.

None of this is an argument against Java as a language. It is an argument against choosing a managed runtime and a vendor platform as the destination for software whose whole value was that it had neither.

04 / COBOL to Java was the wrong modernisation

Native is the point.

The quality worth keeping from COBOL is not the syntax. It is native execution: compiled code, direct access to the operating system, deterministic arithmetic, no runtime to renew. Modern native toolchains give that quality with contemporary type systems, memory safety and tooling, and they run on commodity hardware.

A modernisation that recovers the business rules and rebuilds them as native software keeps what made the original last, removes the hardware and licence dependency, and does not introduce a new platform whose end-of-life will trigger the next migration.

• Compiled, native code with no application server or virtual machine to upgrade
• Exact decimal arithmetic preserved, with the conversions and rounding rules written down
• Batch and transaction behaviour reproduced and compared against the original
• One boundary moved at a time, with a way back until the comparison holds

05 / COBOL to Java was the wrong modernisation

What to do instead.

Start by reading what you have. An investigation of the source, copybooks, job schedules, interfaces and data recovers the rules the business depends on and the limits it has outgrown. That is the software archaeology we describe elsewhere on this site, and it decides the path rather than following a predetermined one.

Then move one boundary at a time. Define a component that can change independently, give it a stable interface to the rest of the system, introduce the native replacement behind that boundary, and compare its behaviour against the original with agreed cases before it carries the load. Rehearse the data migration with representative data. Keep a way back until the comparison holds.

If the estate you are looking at is already Java, the same method applies. The conversion recorded the rules once; they can be recovered again, this time without inheriting the runtime.

06 / COBOL to Java was the wrong modernisation

How to tell which situation you are in.

Ask who can explain the core today, what it costs to run per year including licences and hardware, what the vendor support dates are for every runtime in the path, and how long the last significant change took to make safely. If the honest answers are nobody, more every year, soon, and months, the question is not whether to modernise. It is whether to do it in a way that has to be done again.