MIGRATING COBOL TO JAVA
Migrating COBOL to Java: Every “flat flow” has gaps—stop fooling yourself
I’ve seen a lot of teams migrating COBOL to Java get stuck arguing between two camps.
One side pushes for direct code-to-code translation—fast, mechanical, “safe.” The other insists on going through documentation first—code to doc to code—so everything is specified before implementation.
It sounds like a meaningful debate, but honestly both approaches are just different versions of the same thing: a flat flow. And every flat flow has gaps. Always. Pretending that picking the “right” one will save you is just self-deception.
Before getting into the details, there’s something more fundamental that people tend to avoid saying out loud.
1. Migrating COBOL to Java is not modernization
This might sound harsh, but let’s be precise. Moving from COBOL to Java in 2025 is not “modernizing”, it’s catching up to what the industry standardized 10–15 years ago.
Java has been around since 1995. The Spring ecosystem matured in the early 2000s. Microservices became mainstream around 2014. So if you’re migrating a COBOL system to Spring Boot today, you’re not moving forward—you’re closing a gap that’s been there for over a decade.
Real modernization looks very different. It’s about rethinking how systems behave, not just what language they’re written in. It’s about event-driven architectures instead of nightly batch jobs, real-time data pipelines instead of flat-file ETL, cloud-native and serverless designs instead of monoliths on VMs. It’s about API-first thinking, AI-augmented workflows, and architectures that can actually scale with the business.
If you’re moving to a Java monolith, you’re not escaping legacy—you’re translating it. In many cases, you’re just replacing one form of legacy with another. Even Spring Boot, in 2025, is no longer where new systems are being invented.
So let’s call it what it is. If you’re spending millions migrating COBOL to Java, you’re paying off technical debt. That’s necessary. But it’s not innovation. It’s cleanup. And cleanup doesn’t magically give you a new house, it just makes space for one.
2. Code → code: the “faithful” illusion
The “code to code” mindset often sells itself as being faithful. In reality it’s a trap.
COBOL and Java don’t just differ in syntax—they represent different paradigms. COBOL is procedural and deeply tied to mainframe concepts. Java is object-oriented and ecosystem-driven.
A one-to-one translation produces something awkward: Java written in a COBOL style. Huge classes, pseudo-global state, no real use of the ecosystem. It runs, but it ages badly. Maintenance becomes painful, and five years later another migration conversation begins.
Worse, code-to-code faithfully carries over everything—including decades of accumulated junk. Dead code, duplicated logic, forgotten flags for long-retired customers—none of it disappears. It just gets rewritten in a more fashionable language. Fun right?
3. Code → doc → code: a more dangerous gap
The “code to doc to code” approach looks more disciplined. It introduces structure, allows review, and feels closer to best practice.
But the biggest issue is rarely acknowledged: the moment you convert code into documentation, you start losing information.
Documentation is an abstraction. Someone has to decide what matters and what doesn’t. But COBOL systems are full of subtle, implicit behaviors that don’t translate cleanly.
So the document looks elegant. It gets approval. It presents well. Then the Java system is built against it and tested against the original COBOL—and it doesn’t match.
At that point the team is stuck. The document has become the “source of truth”, but it’s incomplete. Debugging turns into guesswork.
On top of that, documentation goes stale almost immediately. Production systems don’t freeze. The doc drifts away, and nobody updates it.
4. A more resilient flow: code → code → doc → code
A more practical approach is adding an intermediate step.
Start with the original COBOL as the ground truth. Then build an intermediate Java version that preserves behavior as closely as possible. It doesn’t need to be pretty. Often it’s not.
Only after that do you write documentation, grounded in both the original system and the intermediate translation. Then you implement the clean Java version, validating continuously against the original.
The key difference is simple: COBOL never stops being the reference. Documentation doesn’t replace it.
5. The common failure mode
There is a very common failure mode here.
Teams build the intermediate version, it works, deadlines approach, and someone decides to ship it “for now”. That temporary solution becomes production.
Optimization never happens. The same technical debt just moves from mainframe to JVM.
Avoiding that requires discipline. Intermediate code must never be treated as a deliverable. You need strong regression testing. And documentation should follow understanding, not precede it.
In reality whether that discipline holds depends more on leadership than engineering.
6. When flat flows are acceptable
Not every project needs the full multi-step approach.
Small modules with limited logic can get away with direct translation. Temporary lift-and-shift can work if there is real budget for refactoring later. Automated tools already use intermediate representations internally anyway.
But large enterprise systems rarely fit these conditions.
7. What actually matters
The debate about flow is secondary.
What matters is whether the team is willing to face two uncomfortable truths.
A 30-year-old COBOL system is complex because it has survived 30 years of change. Underestimating that is risky.
And this work is not a breakthrough. It’s necessary, but it’s cleanup. Once you’re done, you’re not ahead—you’re just catching up.
Successful migration doesn’t come from diagrams or choosing between three steps or four. It comes from validating against reality. From being willing to say “we don’t fully understand this yet”.
Documentation is a thinking tool, not a replacement for the system. The goal is simple: the new system must do everything the old system does, correctly—and then improve from there.
And once the cleanup is done, don’t get comfortable. Real modernization is still ahead.