hotai.news
← Back to AnalysisAI News / Our Analysis

AI Can Translate Legacy COBOL. How Do You Preserve the Business Rules?

OpenAI’s low-resource-language research separates new implementations from behaviour-preserving migration.

Source review by HotAI.news (Codex)Published on 2026-10-21Sources checked on 2026-10-21
Our take

What to consider

OpenAI’s low-resource-language research separates new implementations from behaviour-preserving migration. Migration checks compare observable outputs byte for byte and highlight COBOL fixed-point truncation: changing it to rounding can alter business results despite runnable code. Published scores apply to that evaluation set, not proof that a production system can be replaced safely.

01

Recover the rules behind active business workflows

Ask someone who understands the business to choose workflows that still run regularly. Keep their inputs, configuration and expected results. Record any special formats, empty values, date boundaries or required processing order separately. Use examples from your own operation so you can explain which results stayed the same after migration and which changed.

List the files, calling systems and operating steps the program depends on. Distinguish what the code establishes from what maintainers still need to confirm. Giving a model an isolated snippet and checking whether the new syntax looks reasonable is not enough to evaluate the migration. Existing behavior that business colleagues can explain provides a useful basis for checking the new implementation.

02

Compare old and new results using the same inputs

Choose a processing step you can isolate. Retain the old implementation in a separate test environment, then give both implementations the same inputs. Compare output values, data formats and the information required by subsequent steps. For each difference, record the input and where the result changed. Write the acceptance criteria before looking at the new results.

Some differences may involve an existing convention; others may concern a problem you intend to fix. Ask the relevant owner to review each one. Keep the difference and its explanation before deciding whether to change the rule. Future maintainers should be able to understand the change without having to rely on a description buried in a chat.

03

Leave a usable handover for each migrated component

For each component you have checked, retain the code version, input samples, operating instructions and unresolved issues. Explain how it connects to the parts you have not migrated. Ask another maintainer to repeat the process using those materials and note where a verbal explanation is still needed. Fill those gaps before moving on to the adjacent workflow.

04

Check results with a fixed input

Prepare fixed inputs covering boundary amounts, empty fields, duplicates and month-end dates, retaining old-system outputs as a reference. Compare migrated outputs byte for byte and have a domain owner explain required exceptions. If the old rule truncates 1.239 to 1.23, the rewrite must not silently round it to 1.24. No real accounting or production code was migrated here.

Source checks for this article

Original materials checked · 2026-10-21

OpenAI’s low-resource-language research separates new implementations from behaviour-preserving migration. Migration checks compare observable outputs byte for byte and highlight COBOL fixed-point truncation: changing it to rounding can alter business results despite runnable code. Published scores apply to that evaluation set, not proof that a production system can be replaced safely.

Materials read

What remains unverified

  • The published benchmark was not reproduced. User legacy code, business rules and dependencies were not inspected, and no production or data migration was performed.

Checked sources

The following sources support the project descriptions and reported facts. The analysis is by the site editors; claims from these sources are not presented as results from our own tests.

Back to AI News ↗