On October 19, OpenAI published the results of an assessment dedicated to the migration of programs written in legacy programming languages, including COBOL, to languages such as Java, C++, Kotlin, Python, and Rust.
According to the results released by the company, GPT-6.1 Sol achieved 86.6% accuracy with low reasoning effort, compared to 5.4% of the previous generation. With greater reasoning effort, the result reached 97.9%.
The evaluation criterion is rigorous: a migration is only considered correct when it passes all hidden tests, which require byte-for-byte parity in observable outputs. In other words, the new program must produce exactly the same results as the original.
It is a significant advancement for the realm of corporate systems. But there is a question that deserves attention: faithfully reproducing the behavior of a system does not mean that all the rules embedded in it should continue to exist.
It is worth noting that these percentages were released by OpenAI itself and correspond to a specific assessment, not a guarantee of performance in real migration projects.
What parity guarantees and what it does not answer
Byte-by-byte parity confirms that the migrated system reproduces the observable results of the original system. This is an important requirement for a technically consistent migration.
However, this equivalence also preserves behaviors that may have arisen from deliberate decisions, regulatory requirements, operational adjustments, or temporary solutions that remained in the system over the years.
OpenAI itself presents a clarifying example: COBOL's fixed-point arithmetic may discard excess decimal places unless rounding is explicitly requested.
A rewrite that starts rounding these values may function without presenting execution errors, but produce different financial results.
Now, consider the reverse scenario. If the migration perfectly preserves the original truncation, it will be technically correct according to the parity criterion. But this does not clarify whether the behavior was defined by a regulatory requirement, by a business convention, or by a characteristic that remained in the code without subsequent review.
For the parity test, these situations may produce exactly the same result. For the business, however, their implications can be very different.
This distinction was also highlighted by a professional who reported having developed COBOL for large insurance companies and airlines. Commenting on the results, he noted that he would like the business stakeholders to approve the rules before a migration of this type.
The reflection summarizes an essential point: technical validation does not replace the approval of those responsible for business decisions.
When the code becomes the specification
When explaining why the migration of legacy languages is complex, OpenAI recognizes three recurring difficulties: incomplete documentation, absence of the original developers, and business rules that exist only in the code.
In corporate applications that have been in production for decades, this scenario is recurring.
The specification was documented at a certain point, but the system continued to evolve. New products, tax changes, business exceptions, and operational adjustments have been incorporated over time.
Each change left its mark. In some cases, the documentation did not keep pace with this evolution. Gradually, the code itself began to concentrate information that was no longer recorded elsewhere.
It is in this context that a fundamental question arises for any modernization project:
Does the organization know exactly what decisions its system is making on behalf of the business?
OpenAI also emphasizes that applying these models in production environments still requires specialized review and testing related to business rules and system dependencies.
This recommendation highlights a step that cannot be ignored: understanding and validating the functioning of the application before transforming it.
The work that needs to happen before migration
If artificial intelligence reduces the effort needed to translate code, the focus of modernization projects needs to concentrate even more on understanding the existing system.
This involves some important steps:
Making the rules understandable: identify behaviors in the code and document them in process models, decision tables, or specifications that can also be analyzed by the business areas.
Classify the identified behaviors: differentiate business rules, regulatory obligations, operational decisions, and temporary solutions that have been incorporated into the system.
Map dependencies: understand interfaces, files, batch routines, integrations, and other components that influence the functioning of the application.
Involve the business stakeholders: bring the identified rules to the areas of operations, finance, compliance, risk, and legal so they can assess their validity and necessity.
These areas do not need to interpret COBOL code. They need to understand the processes and decisions that the system executes to evaluate if they remain appropriate.
From this review, two forms of validation begin to work together: parity tests check if the new code reproduces the behavior of the previous one; business approval determines which rules should continue guiding the operation.
One validation does not replace the other.
Modernizing also means deciding what to evolve
There is another important aspect in this discussion: modernizing does not necessarily mean rewriting the entire application.
Depending on the characteristics of the environment, evolution can combine different approaches: preserving functionalities that continue to meet the business needs, modernizing specific components, integrating existing systems through APIs, and developing new capabilities without discarding the entire already consolidated structure.
The choice depends on an adequate understanding of the architecture, the business rules, the dependencies, and the organization's objectives.
It is precisely in this scenario that artificial intelligence can expand the possibilities for modernization. It can support activities of analysis, documentation, translation, and development, reducing efforts in stages that historically required a lot of specialized work.
But technology does not eliminate the need for knowledge about corporate environments nor does it transfer the responsibility for business decisions to the algorithm.
The perspective of INTERON
INTERON's experience with corporate applications and COBOL environments reinforces the importance of treating modernization as an evolutionary process, not just as a technological replacement.
Throughout its journey, the company has faced challenges related to the continuity of critical systems, the preservation of operational rules, and the need to connect consolidated applications to new technologies.
This experience helps to understand that the greatest challenge of modernization is not always in the language used or the target platform. Often, it lies in the accumulated knowledge within the application and the decisions that support essential processes for the organization.
Therefore, each initiative needs to consider not only what can be technically transformed but also what needs to be preserved, adjusted, or replaced.
The advancements in artificial intelligence represent an important opportunity to accelerate the evolution of legacy applications. However, the speed of transformation should not precede decisions that depend on a deeper understanding of the business.
AI can help translate code. But understanding what it represents, validating its rules, and deciding what should continue to be part of the operation still requires knowledge, experience, and participation from the people responsible for the business.
After all, before asking if a system can be migrated, it is necessary to understand what the organization really wants to preserve.
INTERON
Evolving Business Applications
Source of the mentioned results: "Advancing coding in low-resource programming languages", published on October 19, 2026.