Modernization and software Analysis
AI for COBOL and Mainframe Modernization: What It Changes and What It Doesn't
AI has made reading, documenting and testing a COBOL estate far cheaper. The hard part is unchanged: proving, record for record, that the replacement behaves exactly like the original before anyone switches the old system off.
For CTOs and CIOs deciding whether to retain, wrap or replace COBOL and mainframe workloads now that AI tools promise to do much of the work.
The short answer
AI makes COBOL and mainframe modernization cheaper at the front: it reads code, documents business rules, maps dependencies and drafts tests. It does not change what makes these systems hard to replace: runtime and data semantics, batch performance, operational knowledge and the evidence regulators require. Use AI to understand the estate, then prove the new system matches the old one output for output before any cutover.
Key takeaways
- Put AI to work on comprehension first: documentation tied to source lines, a business-rule catalog, a dependency map and characterization tests. That is where it saves the most and risks the least.
- Much of a COBOL program's behavior lives outside the source, in compiler options, packed-decimal arithmetic, EBCDIC data and the batch schedule. Identical source can produce different results under different compile options.6
- Write the equivalence specification before converting anything, then cut over in stages: characterization tests, replay, parallel run, canary, cutover, each gated by clean reconciliation.
- Decide per workload. Gartner expects more than 70% of mainframe exit projects started in 2026 to miss their intended benefits by overestimating generative AI, and recommends matching each workload to the right platform.4
- Regulators already ask for the evidence a proper proof produces: DORA requires a risk assessment of legacy systems before and after new connections, and RBI requires sign-offs at each stage of a data migration.912
On February 23, 2026, a major AI lab said its coding tool could automate the exploration and analysis work that drives most of the complexity in COBOL modernization. IBM's shares closed about 13% lower that day, the company's steepest one-day fall since October 2000 at the time.12 Boards with mainframe estates have asked ever since whether AI can now convert their COBOL and let them switch the mainframe off. AI has made the estate far cheaper to understand. The hardest part of the work is where it always was: proving that the replacement behaves like the original.
- 13%fall in IBM's share price on February 23, 2026, the day an AI lab announced COBOL modernization tooling1
- 70%+of mainframe exit projects started in 2026 that Gartner expects to miss their intended benefits by overestimating generative AI4
- 3 of 10critical federal legacy systems flagged by GAO in 2019 that agencies had finished modernizing by February 20255
What changed in 2026, and what the market over-read
What changed in 2026 is the cost of comprehension. The announcement described a tool that maps dependencies across a codebase, documents workflows and surfaces risks that would take human analysts months to find.1 Those are the discovery and analysis phases. Investors read the news as something larger: that code conversion, and with it the exit from the mainframe, had become a solved problem.
Two responses frame the debate. IBM answered the same day that translation captures almost none of the real complexity, which sits in data architecture, runtime replacement, transaction integrity and the non-functional requirements built into the platform, and that code is where modernization starts.3 In June, Gartner predicted that more than 70% of mainframe exit projects initiated in 2026 will fail to produce their intended benefits because buyers overestimate generative AI tooling, and that by 2030, 75% of vendors in the mainframe exit market will pivot their business models or cease operations.4 IBM sells the platform and the AI lab sells the tool, so read both statements as advocacy. Each contains something true.
The difficulty predates AI. GAO reports that one Defense Department system was first developed in 1964; in March 2000 the department announced it would be retired by October 2002, and it was not replaced, because of challenges with the existing technologies and architectures in supporting complex system functions.5 Of the 10 critical federal legacy systems GAO identified in 2019, agencies had completed three modernizations by February 2025.5 Reading the code was never the only obstacle.
One distinction matters before any plan is written. IBM says roughly 40% of COBOL runs on Windows, Linux and other distributed platforms.3 COBOL modernization is a language and skills problem. Mainframe modernization is a platform problem: CICS transactions, IMS and Db2 data, VSAM files, JCL job streams, the batch schedule and the throughput they deliver together. Most large estates have both, and the two need different plans.
Where AI helps in COBOL and mainframe modernization
AI helps most with the work that used to come before any new code was written: reading, documenting, mapping and testing. Five uses stand out:
- Comprehension and documentation A plain-language account of each program, paragraph and copybook, with every statement tied to the source lines it came from so a reviewer can check it. It is the fastest way to cut key-person risk.
- Business-rule extraction Rules buried in nested IF and EVALUATE logic, level-88 conditions and hard-coded tables, pulled into a catalog the business owner can confirm, change or retire. Expect part of what you find to be dead: rules for products you no longer sell.
- Dependency mapping Which programs read and write which VSAM files, Db2 tables and sequential datasets, which JCL steps run them, which CICS transactions call them, and where two programs are coupled only through a shared copybook or file. The map sets the order of the work.
- Test generation Characterization tests drafted from production-like inputs, plus edge cases at the boundaries where COBOL behaves in ways a modern language does not: field overflow, sign handling, date rollovers, blank and low-value numeric fields.
- Conversion drafts For a well-bounded module with tests around it, a model's first draft in the target language saves real effort. It stays a draft until reconciliation against the original says otherwise.
Treat every AI output as a claim to be checked. Generated documentation tends to fail in the unusual branches, and those often exist for a legal or contractual reason. Score it against a graded sample checked by someone who knows the system; our guide to LLM evaluation covers the method.
Where AI does not help: runtime, data and operations
AI reads source code, and a large part of a mainframe application's behavior is absent from the source. It sits in compiler options, data formats, the transaction monitor, the job scheduler and the heads of the operations team. A model that has read every line can still produce a conversion that fails on the first real file.
| Behavior | Where it lives | What goes wrong in a conversion |
|---|---|---|
| Numeric truncation | Compiler options such as TRUNC, PICTURE clauses | The same MOVE gives different results under different options; the converted code must match the options each program was built with |
| Decimal arithmetic | COMP-3 packed decimal, fixed-point intermediate results, ROUNDED | Amounts carried in binary floating point drift by fractions of a cent; the target needs decimal types with explicit scale and rounding |
| Character encoding and sort order | EBCDIC code pages | Sorted reports, key ranges and merge logic change order once data moves to ASCII or Unicode |
| Record layouts | Copybooks, REDEFINES, OCCURS DEPENDING ON | One byte range holds different types depending on a flag field; a naive schema mapping corrupts records |
| Transaction boundaries | CICS units of work, VSAM and Db2 locking | Commit and rollback points move, leaving partial updates after a failure |
| Batch flow | JCL, condition codes, restart steps, the scheduler | Job ordering, restart after an abend and the overnight window live in operations, outside every program |
| Throughput | The platform's I/O and workload management | A batch that fits its window on the mainframe may overrun on the new platform at full volume |
| Operational knowledge | Runbooks and people | Month-end workarounds and known bad records are nowhere in the code |
IBM's own documentation for the TRUNC compiler option shows how deep this goes. Moving 123451 into a binary field defined as PIC S99 yields 51 under TRUNC(STD) and -7621 under TRUNC(OPT) or TRUNC(BIN), and IBM notes that under TRUNC(OPT) the truncation cannot be predicted without seeing the code generated for the statement.6 Encoding has the same trap: in EBCDIC, lowercase letters sort before uppercase and letters sort before digits,7 the reverse of ASCII on both counts. A conversion has to start from the compile options each program was built with and the code page each file was written in.
Line-by-line translation versus refactoring
Line-by-line translation produces code in a new language that still thinks in COBOL; refactoring keeps the behavior and changes the structure so a modern team can own it. Engineers call the first result JOBOL: Java classes named after COBOL paragraphs, fields still called WS-TOTAL-AMT, GO TO logic simulated with state flags, fixed-length strings padded with spaces, and a runtime library that emulates COBOL semantics underneath. It compiles, and it may pass tests. It also keeps every constraint of the old design and needs engineers who can read COBOL to maintain the Java.
Transliterate
Line by line, same structure
- Fastest to produce, easiest for AI
- Behavior close to the original if the runtime library is faithful
- Hard to change: the new code reads like the old code
- Leaves you dependent on the emulation library
Refactor
Same behavior, new structure
- Slower, and needs engineers who know both languages
- Behavior held constant by characterization tests
- Code a modern team can own and change
- The default for workloads you intend to keep evolving
Rewrite
Rules re-specified, new design
- Right when the business process itself is changing
- Behavior is redefined, so equivalence becomes a business sign-off
- Highest risk of losing rules nobody documented
- Needs the full business-rule catalog first
Transliteration is defensible in two cases: as a deliberate first step with the refactor funded and scheduled behind it, and for code that will be retired before anyone needs to change it. Everywhere else it moves the maintenance problem into a new language and adds a runtime library few people understand.
How to prove the new system behaves like the old one
You prove behavioral equivalence by running both systems on the same inputs and reconciling every output, at increasing scale, until each difference is either fixed or accepted in writing by the business owner. Start by writing the equivalence specification, before any code is converted. It lists every output the system produces (files, reports, database changes, messages, return codes, downstream feeds), the matching rule for each (byte-identical, identical after a documented normalization such as encoding or timestamps, or within a stated tolerance) and the person who signs each one off. Without it, every difference found later turns into an argument.
- CharacterizeCapture current behavior program by program, from production-like inputs, as automated tests.Every converted module passes the tests the COBOL passes.
- ReplayRun captured production days, including a month-end, through both systems in a test environment and reconcile the outputs.Every break is classified and closed.
- Parallel runBoth systems process live input. The mainframe stays the system of record.An agreed run of consecutive cycles with no unexplained breaks, covering the calendar events in scope.
- CanaryThe new system becomes the system of record for one slice: a product, a region or a range of accounts. The old one runs alongside for comparison.Reconciliation stays clean and a rollback has been rehearsed.
- CutoverThe new system takes all traffic. The old one stays available, read-only, for rollback and audit.Decommissioning approved by the business owner and the risk function.
Reconciliation is automated and runs every cycle. Control totals come first: record counts, sums of every amount field and hashes of sorted keys. A field-level comparison follows, with the normalization rules from the specification applied. Every break becomes a ticket classed as a defect in the new system, a defect in the old one, or an accepted difference.
The cost of an all-at-once cutover is on the public record. In April 2018 a UK bank moved its customer and corporate services onto a new IT platform. The data migrated successfully; the platform immediately experienced technical failures, affecting all of the bank's branches and a significant proportion of its 5.2 million customers, and business as usual returned only in December 2018. The FCA and PRA fined the bank £48.65m for failing to organize and control the migration adequately.11 Correct data is necessary. The whole running system has to be proven.
Data migration: the part that fails quietly
Data needs its own proof, because records can load, counts can match and the meaning can still be wrong. AI is useful for reading copybooks and drafting field mappings. These checks decide whether the mapping is right:
Data checks before any cutover
- Every copybook is mapped to a target schema, including each REDEFINES and OCCURS DEPENDING ON, with the field that decides the layout named.
- Packed and zoned decimals land in decimal types with scale preserved, and sign values are validated on the way in.
- EBCDIC is converted using the exact code page each file was written in, with a written rule for bytes that do not map.
- Spaces, low-values and high-values in numeric fields have an explicit rule, agreed with the business owner.
- Two-digit years, century windows and sentinel dates such as all nines are handled and tested.
- Every file reconciles old against new on record counts, sums of each amount field and a hash of its keys.
- The business owner and the application owner sign off each migration stage, and the audit trail is kept. In India, RBI already requires both of regulated entities.12
Sequence the work with the strangler fig pattern
The strangler fig pattern replaces a legacy system one bounded capability at a time: route its traffic through a layer you control, build the new version behind that layer, prove it by reconciliation, then retire the old code path. Its best-known description has you build small additions on top of, yet separate from, the legacy code and move behavior across piece by piece, and argues that the reduced risk and earlier value outweigh the cost of the temporary architecture it needs.8
In a mainframe estate that temporary architecture is concrete: an API or routing layer in front of CICS transactions, replication or change-data capture to keep old and new data stores consistent, and the reconciliation jobs that run every cycle. Start with a slice that has clear inputs and outputs and a small blast radius, such as an inquiry service or a statement run. Leave the core posting engine until the pipeline and the team have been proven on work that cannot touch a customer's balance. Split batch by job stream or by file, and online work by transaction.
Retain, wrap or exit: a decision matrix per workload
Decide per workload, because the right answer for a stable settlement batch is rarely the right answer for a customer inquiry service. Gartner's advice is a platform-smart approach that aligns each workload with the right environment, in place of an AI-driven exit of the whole estate.4
| Workload | Usual choice | Why | Where AI helps |
|---|---|---|---|
| High-volume batch posting or settlement with stable rules | Retain and modernize in place | Throughput and the batch window are the platform's strength, and the rules rarely change | Documentation, tests and reduced key-person risk |
| Online inquiry and account servicing in CICS | Wrap with APIs, then strangle slice by slice | New channels need access now; logic can move one transaction at a time | Mapping transactions to API contracts, drafting adapters |
| Rules that change often: pricing, eligibility, product setup | Extract the rules, then move them | Change is where the cost sits, so a rules service in your environment pays back | Extracting and cataloging rules for business confirmation |
| Reporting and analytics extracts | Exit to your data platform | Read-only, easy to reconcile, small blast radius | Mapping file layouts, generating conversion and reconciliation code |
| Packaged or vendor-supplied COBOL | Replace with a product where one fits | You do not own the code, and the supplier's roadmap decides its future | Comparing current behavior with the product's configuration |
| Dormant or duplicate programs | Retire | No callers in the dependency map and no owner who needs them | Finding unused programs and dead paths |
| COBOL on Windows or Linux | Refactor or rehost | No mainframe tie; the problem is the language and the skills | Conversion drafts under characterization tests |
Wrapping is often the fastest route to value. Expose CICS transactions and batch outputs as versioned APIs in your environment. Where AI agents need access, put an MCP server in front of those APIs, with read-only tools first and write tools behind approval; our guide to MCP and A2A in the enterprise covers the controls. For EU financial entities, a new connection carries an obligation of its own: DORA requires a specific ICT risk assessment of all legacy ICT systems at least yearly, and before and after connecting technologies, applications or systems.9
What regulators expect when you modernize a critical system
Regulators expect a modernization of a critical system to carry the same evidence as any major change: a documented plan, controlled and tested change, data integrity proven at each stage, and continuity of important services throughout. None of the rules below mentions AI; all of them ask for records a proper proof produces anyway.
| Jurisdiction | Rule | What it asks of a modernization |
|---|---|---|
| EU financial entities | DORA, Regulation (EU) 2022/2554, applying since January 17, 20259 | A yearly risk assessment of legacy ICT systems, repeated before and after new connections (Article 8(7)); every change recorded, tested, assessed, approved, implemented and verified in a controlled manner (Article 9(4)(e)) |
| UK banks, insurers and other in-scope firms | FCA PS21/3, operational resilience10 | Since March 31, 2025, the ability to remain within impact tolerances for each important business service, so a cutover plan must show it stays inside them |
| India: banks and larger NBFCs | RBI IT Governance Directions, in effect since April 1, 202412 | A documented data migration policy ensuring integrity, completeness and consistency, stage sign-offs and audit trails |
| US federal agencies | GAO's criteria in GAO-25-1077955 | Modernization plans with milestones, a description of the work and the disposition of the legacy system |
GAO found that of the 11 federal legacy systems most in need of modernization, only three had plans covering all three of those elements, and two had no plan at all. Disposition of the legacy system was the element least often covered in full.5 Decide early how the old system will be kept, archived or switched off, because its data and logs may be needed for audit long after cutover.
In the application modernization work we do, the order is fixed: AI-assisted documentation and dependency mapping first, the equivalence specification signed before any conversion, and cutover only on reconciled evidence. The tools will keep improving. The proof is what lets a bank, an insurer or an agency turn the old system off.
Questions leaders ask
Can AI convert COBOL to Java?
Yes. AI can turn COBOL into Java that compiles and often runs, and for well-bounded modules the draft saves real effort. Whether it is correct is a separate question: much of a COBOL program's behavior depends on compiler options, packed-decimal arithmetic, EBCDIC data and the batch environment, none of which the source fully shows.6 Treat the output as a draft until it passes characterization tests and matches the original's outputs in a parallel run.
Why do mainframe migrations fail?
Most fail on what sits outside the code: data semantics, batch performance, operational knowledge and too little parallel running before cutover. Gartner expects more than 70% of mainframe exit projects started in 2026 to miss their intended benefits because buyers overestimate generative AI tooling.4 Migrations that succeed define equivalence first, move one capability at a time and cut over only when reconciliation of old and new outputs is clean.
Should we keep the mainframe or migrate off it?
Decide per workload. Stable, high-volume batch often belongs on the platform it was built for, modernized in place. Services that need new channels can be wrapped with APIs and moved slice by slice. Reporting extracts and dormant code are usually the easiest to move or retire. Gartner recommends this platform-smart approach, matching each workload to the right environment, over a wholesale AI-driven exit.4
How long does a COBOL to Java migration take?
The duration is set by the proof more than by conversion speed. The drivers are the number of programs and how tightly they share data, the volume and formats of the data, the batch window, and how many business cycles the parallel run must cover. If year-end or regulatory reporting is in scope, the proof has to include one, so the business calendar sets the minimum for any honest plan.
What is the strangler fig pattern in legacy modernization?
It is a way to replace a legacy system gradually. You put a routing layer in front of it, build new capabilities beside it, move behavior across one piece at a time and retire each old path once the new one is proven.8 It costs some temporary architecture, such as data replication and reconciliation jobs, and in return avoids a single high-risk cutover of the whole system.
What does DORA require for legacy systems?
DORA has applied to EU financial entities since January 17, 2025. Entities other than microenterprises must run a specific ICT risk assessment on all legacy ICT systems at least yearly, and before and after connecting technologies, applications or systems. Every ICT change must be recorded, tested, assessed, approved, implemented and verified in a controlled manner.9 A modernization program's plans, test evidence and reconciliation records are how an entity shows it met both.
Sources
- IBM is the latest AI casualty. Shares tank 13% on Anthropic programming language threatCNBC, February 23, 2026
- IBM Sinks Most Since 2000 as Anthropic Touts Cobol ToolBloomberg, February 23, 2026
- Lost in Translation: What the AI code debate keeps getting wrongIBM Newsroom, February 23, 2026
- Gartner Predicts More Than 70% of Mainframe Exit Projects Will Fail Due to Overestimation of Generative AI's CapabilitiesGartner, June 18, 2026
- Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems (GAO-25-107795)U.S. Government Accountability Office, July 17, 2025
- TRUNCIBM, Enterprise COBOL for z/OS 6.4 documentation
- EBCDIC collating sequenceIBM, Enterprise COBOL for z/OS 6.4 documentation
- Strangler FigMartin Fowler, martinfowler.com, August 22, 2024
- Regulation (EU) 2022/2554 on digital operational resilience for the financial sectorOfficial Journal of the European Union
- PS21/3 Building operational resilienceFinancial Conduct Authority, March 29, 2021
- TSB fined £48.65m for operational resilience failingsFinancial Conduct Authority, December 20, 2022
- Reserve Bank of India (Information Technology Governance, Risk, Controls and Assurance Practices) Directions, 2023Reserve Bank of India, November 7, 2023
Written by DigyAi Engineering from the systems we build and run. Every figure links to its public source, and every link and figure was checked on September 26, 2026. No client data appears in our insights.
