An article by Uwe Graf, Head of Consulting at EasiRun.
When people talk about modernizing COBOL applications today, it rarely takes long before artificial intelligence enters the conversation. Analyze code, identify business rules, generate Java. What only a few years ago sounded like a complex migration project is now often presented as something that can be done at the push of a button.
AI does indeed open up new possibilities. Even so, now is a good time to consider a different question: Does a proven application really need to be reinterpreted if its existing logic can be transferred to a new technical environment in a controlled manner?
This idea has long been at the heart of P3/COBOL. And a recent research paper on translating Fortran to Python provides an interesting argument for why deterministic methods continue to play an important role in modernization.
What Fortran Research Has to Do with COBOL
As LegacyIT.de reports in its article on the FGPT Fortran transpiler, researchers at France’s Institut Pierre-Simon Laplace deliberately rely on traditional compiler technology when transferring scientific applications. The source code is analyzed in a structured manner, dependencies are identified, and translation takes place through defined intermediate steps. The goal is to preserve the semantics of the original program and make the results reproducibly verifiable.
The authors explicitly distinguish their approach from translation based solely on Large Language Models. With large codebases, results that merely look plausible are not enough. Consistent transformations, numerical accuracy, and comparison with reference results are critical. The underlying research paper, “A Fortran General-Purpose Transpiler: Proof of Concept,” describes this approach and the testing conducted so far.
This is not to say that AI is unsuitable for modernization. Rather, it is a reminder that generating code and demonstrating that it behaves correctly are two different tasks.
For COBOL applications in banks, insurance companies, and other enterprises, this distinction is particularly important. It is not enough for a new implementation to produce the same result in most cases. Rare business scenarios, rounding rules, data formats, and special cases that have evolved over decades must also be taken into account.
This Is Exactly Where P3/COBOL Comes In
The fundamental idea behind P3/COBOL is not to replace existing COBOL applications prematurely with a complete rewrite. Instead, the existing software is used as the functional foundation for the transition to Java.
P3/COBOL is a cross-compiler that translates COBOL into Java source code. It offers several possible paths: companies can retain their COBOL sources while using Java as the target environment, combine COBOL and Java at the developer level, progressively evolve the code using Java Augmented Syntax, or migrate directly toward an application that will ultimately be maintained in Java.
What matters is not simply that Java code is produced at the end of the process. What matters is that the transformation is based on defined rules and that each program does not have to be functionally reinterpreted every time it is translated.
This is the key difference compared with a purely generative approach. Under the same conditions, a deterministic compiler applies the same transformation rules. A language model, by contrast, may produce a different implementation when asked to generate the code again. This does not automatically make AI inferior, but it does create different requirements for control and quality assurance.
Preserve the Logic First, Then Change It Selectively
In many modernization projects, a change of technical platform is combined with a functional and architectural redesign. This can make sense, but it also increases the number of changes that have to be managed simultaneously.
P3/COBOL enables a different approach. The existing COBOL logic can first be transferred into a Java-based environment. A decision can then be made about which parts should remain unchanged, which should be optimized, and where a more extensive redesign would actually deliver value.
An important component in this process is Java Augmented Syntax, or JAS. It supports the gradual reformulation of COBOL rules into a form that can be transferred more specifically to Java. This means that the entire application does not have to be understood from scratch and reimplemented all at once. Functional and technical changes can be introduced in manageable steps.
For large applications in particular, this is a significant advantage. The original COBOL application remains available as a reference while individual areas are further developed and their results can be verified.
Why This Matters for Banks and Insurance Companies
Consider a mature application used to calculate insurance benefits. It may contain rules developed over decades, different generations of contracts, and special cases that occur only rarely.
With a complete rewrite, this behavior first has to be understood and then implemented again. Any rule that is overlooked can result in a discrepancy. Particularly critical are errors that do not cause the program to crash but instead produce an incorrect amount only in specific cases.
A controlled transformation takes a different approach. Its first objective is to preserve the existing behavior. Functional enhancements can then be introduced selectively and validated against the existing system.
Of course, even a deterministic compiler does not guarantee that a complex migration will automatically be correct. Different runtime environments, data access mechanisms, interfaces, and technical specifics still need to be examined and tested. Reproducibility does not automatically mean functional equivalence.
However, it does provide an important foundation: if a transformation rule is modified, it is possible to trace what was changed and how that change affects the relevant code. This creates a very different starting point from one in which extensive sections of a program are regenerated each time and subsequently have to be evaluated again.
And What Role Does AI Play?
In my view, it would be wrong to frame this as a choice between P3/COBOL and AI. The two approaches can complement each other effectively.
AI can help analyze COBOL applications, make dependencies visible, document business rules, and prepare test cases. It can also help developers identify suitable areas for subsequent reworking.
Where technically appropriate, the actual transformation can continue to be carried out using defined and reproducible methods. AI and experienced developers can then work together to make the resulting application easier to understand, maintain, and align with an appropriate architecture.
In this way, AI does not replace a modernization methodology; instead, it becomes a tool within a controlled process.
Don't Rebuild Everything—Change What Actually Needs Changing
The Fortran research is still a proof of concept and cannot be applied directly to business-critical COBOL applications. What is interesting, however, is that even when targeting a modern technology, the researchers are once again relying on structured compiler methods, semantic preservation, and verifiable results.
These principles have long been part of the P3/COBOL concept. Existing software is not regarded as an obstacle that needs to disappear as quickly as possible, but as a valuable foundation that can be evolved in a controlled manner.
This does not mean that every application should be translated, nor does it mean that a complete rewrite is inherently the wrong choice. It simply means that the decision should not be driven by the appeal of a new programming language.
After all, modernization is not about replacing as much COBOL as possible with as much Java as possible. It is about preserving proven business logic, reducing technical dependencies, and ensuring that applications can continue to evolve in the years ahead.
Perhaps, then, the most important question is not how quickly we can rewrite an application, but how much of it we actually need to rewrite.