OpenAI Claims Big Gains in COBOL, Fortran and Legacy Code Migration
OpenAI says its models are now better at building and migrating software in COBOL, Fortran and Visual Basic. Engadget
The description appeared in a blog post titled 'Advancing coding in low-resource programming languages' published on October 19, 2026. OpenAI OpenAI classifies COBOL as a low-resource programming language, meaning there is relatively little public code and modern tooling for models to learn from.
OpenAI states that 40% of the world's banks still rely on COBOL systems. OpenAI aims to help banks modernise legacy software their operations still depend on.
To measure capability, OpenAI created an evaluation suite called MultiLangBench. It asks models to create SQLite-compatible database engines, meaning small databases that follow the rules of the widely used SQLite system, in a specified programming language.
On that benchmark, GPT-6 Astra had an average test pass rate of 87.4% across 20 languages, compared to 26.8% for GPT-5.6 Sol. The gap is large. COBOL remains the hardest language in MultiLangBench, with GPT-6 Astra achieving a 72% pass rate for COBOL.
OpenAI also evaluated its models on migrating COBOL programs to C++, Java, Kotlin, Python or Rust while preserving what the programs do. GPT-6.1 Sol achieved 97.9% accuracy on COBOL migration with high reasoning effort and 86.6% accuracy with low reasoning effort. Reasoning effort is the extra time and computing a model spends working through a problem.
OpenAI said applying its behavior-preserving migration capabilities to production software still requires expert review and testing against business rules and dependencies.
Looking at what this means for engineering teams, the reasoning-effort split is the operational detail. High reasoning effort buys more than eleven points of migration accuracy over low reasoning effort in OpenAI's numbers. That delta will map directly to inference cost, latency and review load, in other words computing cost, waiting time and human checking. Teams will have to decide where to spend deliberation. Bulk triage of a large estate may tolerate lower effort with heavier human sampling. Cutover candidates will not.
The broader context here is that migration accuracy and production readiness are different thresholds. A model can preserve observable behavior on a program in isolation and still fail on the system around it. Business rules live outside the source file. So do job control, transaction monitors, batch schedules, data encodings and undocumented dependencies accumulated over years. OpenAI's caution about expert review and testing against business rules and dependencies points to that boundary. For practitioners, the work shifts from rewriting syntax to proving equivalence under operational constraints.
In my view, there is reason for measured optimism. Low-resource languages have been a weak point for code assistants precisely because public corpora and modern tooling are thin. Targeted gains there expand what automation can usefully touch inside banks and other institutions tied to legacy estates. The path is unlikely to be wholesale replacement. It looks more like incremental extraction, with models drafting the target-language equivalent and engineers owning validation. If that pattern holds, the value is less in removing COBOL at speed and more in making modernization continuous without freezing the systems that still run the business.
