The scarce work becomes proving that the migrated system behaves the same, and whoever can do that proof stands to gain.
Summary
On October 19, 2026, OpenAI said it has improved ChatGPT for building and migrating software in COBOL, Fortran and Visual Basic. The announcement names new evaluations for software engineering, SQLite and COBOL migration. It presents these languages as the base of software that banks, governments and businesses rely on. The material we have shows no scores, no independent replication and no named production migrations.
What happened
The announcement brings three low-resource languages into OpenAI's main coding work. "Low-resource" means little public code exists to train on. OpenAI frames the effort around two jobs: building new software in these languages and migrating old software out of them. It also names the areas it now evaluates: general software engineering, a SQLite-related task set and COBOL migration. That is narrower and easier to check than a general claim that coding got better. But the primary material we have gives no benchmark numbers, task counts, pass criteria or customer outcomes. It supports the claim of a targeted capability push. It does not support a claim of reliable end-to-end migration.
This is not OpenAI's first step into the area. According to OpenAI's developer cookbook (d1), the company already presented COBOL modernization as a Codex use case in November 2025. The cookbook calls code modernization a common and valuable use and offers a COBOL-based example. That example is a workflow demonstration, not a production deployment. Our read is that the October release takes an existing enterprise pitch and turns it into something OpenAI now measures itself on.
What the archive adds
The archive shows that OpenAI is entering a field where competitors already have products. Anthropic publishes a code-modernization plugin for Claude (d2). According to its README, the plugin was shown rewriting AWS's CardDemo sample mainframe application to Java one job at a time. The same README records a case where an environment blocked the work, including a package index that refused installs. The plugin reported the blocker and did not work around it. That behavior matters in regulated settings, because a silent workaround is exactly the kind of change an auditor never sees. The archive also contains Anthropic event coverage connected to AWS (d3), which suggests modernization is being sold through cloud channels as well as directly. Outside the dossier, readers should know that cloud and mainframe vendors already sell their own modernization tooling. Public COBOL benchmarks such as COBOLEval exist, but they test small programming tasks, not whether a migrated enterprise system behaves the same as the original. We have no head-to-head scores comparing the current models.
Trend signal
Frontier labs are moving from broad coding benchmarks to domain-specific ones, and legacy modernization is the obvious niche to target. Fixed specialist evaluations make progress easy to show. Every major model vendor now has a modernization story: OpenAI through Codex since 2025 (d1), Anthropic through its plugin (d2). Our read is that code translation is becoming a standard feature of general models, while the scarce work shifts to verification, dependency discovery and sign-off. Both vendors' published material centers on workflow and guardrails rather than raw translation quality. That suggests they know where the hard part is.
Why now
- An existing use case is maturing. OpenAI was already promoting COBOL modernization through Codex in November 2025 (d1), and this release adds named evaluations.
- Competitive pressure. Anthropic ships a modernization plugin that has been demonstrated on a mainframe sample application (d2), and modernization is also sold through cloud-vendor channels (d3).
- Measurability. Fixed tasks such as SQLite and COBOL migration make progress easier to show than broad coding claims, according to the announcement's framing.
Connections to other events
Who gains:
- Teams and tools that do equivalence testing. If translated code is cheap, buyers will pay for evidence that the new system produces the same output as the old one on real inputs, including decimal arithmetic, copybook layouts and batch-job behavior. A differential harness, which runs both versions on the same inputs and compares the results, becomes the product.
- Engineers who know how the legacy system actually behaves. This one is speculative. Their work may shift from writing code to writing oracles (recorded expected outputs that tests check against) and to reviewing what the agent produced.
- OpenAI, if its named evaluations become the way buyers compare vendors. It would then get to define what "migration quality" means.
Who loses:
- The labor-heavy rewrite share of systems-integrator contracts. If line-by-line translation shrinks, integrators have to move their pricing to assessment, testing and accountability.
- Specialized COBOL models and narrow translators. Their advantage fades if general frontier models close the gap, unless they compete on running on-premises.
- Mainframe-specific modernization platforms, but only partly. They own the integration and the access to the mainframe, which a chat model does not. Our read is that they become places to plug in someone else's model rather than sellers of the model.
All of this depends on OpenAI's gains holding up on real codebases. The evidence does not yet show that.
Why it matters
For builders, the opening is the verification layer, not another COBOL-to-Java translator. That layer needs tools that capture production inputs and outputs, replay them against both the legacy and the migrated system, compare the results field by field and produce reports an auditor can use.
For buyers in banks and government, it is time to rethink how modernization contracts are scoped. If translation gets cheaper, pay for parity coverage and accountability for defects rather than for lines rewritten. Require the same equivalence evidence no matter whose model does the translation, and keep the model swappable. Vendor evaluations are not published in a form you can review, so choose based on a pilot on your own code.
What happens next
- OpenAI publishes quantitative results (scores plus task descriptions) for its COBOL migration evaluation. (6 months, 50%). Watch for: A system card, paper or blog update with numeric COBOL migration scores and a description of the tasks or pass criteria.
- At least one named bank, insurer or government agency publicly credits an OpenAI model for a production COBOL migration. (12 months, 30%). Watch for: A customer case study or joint press release naming the institution, the scope of the migrated system and how the result was validated.
- An independent group publishes a COBOLEval result, or a result on a comparable public COBOL benchmark, for an OpenAI model released after October 2026. (6 months, 45%). Watch for: An arXiv paper or public leaderboard entry listing a post-October-2026 OpenAI model on a public COBOL benchmark.
Limits and uncertainty
We have no quantitative results from OpenAI, so "improved" could mean a large jump or a small one. The SQLite and COBOL migration evaluations are named but not described. We cannot tell whether they test that the migrated system behaves the same, or only that the code compiles and passes unit tests. There is no evidence at all about Fortran or Visual Basic outcomes.
The winners-and-losers picture assumes that translation quality really becomes routine. If models still fail on the hard cases, such as CICS transactions, JCL orchestration and undocumented side effects, then integrators keep their leverage and this take overstates the shift. The details of the Anthropic plugin come from its README, not from an independent audit.
Skill to build now
Practice differential equivalence testing on legacy code. As a first exercise, take a public COBOL sample such as CardDemo, or one of your own batch programs, and record a set of inputs together with the outputs they produce. Have a model translate the program to Java or Python. Then write a script that runs both versions on the same inputs and compares the outputs field by field, with explicit checks on decimal precision and rounding. Log every mismatch. That log is your real evaluation.
Reader takeaway
If you run a legacy estate, fund a differential test harness before you fund any vendor's translation. Pick one batch job, capture its real inputs and outputs, and make "identical output on replay" the acceptance gate that every model has to pass. That gives you a scoreboard you control, whichever vendor's model comes out ahead.
Open question
Suppose an AI-translated banking system passes every parity test anyone wrote, then fails on a behavior nobody recorded. Who carries the liability: the model vendor, the integrator who ran the migration, or the bank that approved the tests?