In February, Anthropic published a post saying its Claude Code tool could modernize COBOL. That day, IBM’s stock fell 13.2%, its steepest one-day drop since October 2000.
Investors heard “AI can rewrite COBOL” and drew a straight line to the end of the mainframe. The reality is more useful, and less dramatic. AI really has changed the economics of COBOL modernization. But the companies saving millions aren’t the ones that pointed a model at their code and hit go. They’re the ones with a plan.
Can AI rewrite COBOL code?
Yes, and it’s getting good at it. Three of the biggest players have shipped tools:
- Anthropic said Claude Code can map dependencies across large COBOL codebases, document workflows and surface risks that “would take human analysts months to surface,” according to CNBC’s coverage of its post. The pitch: “Legacy code modernization stalled for years because understanding legacy code cost more than rewriting it. AI flips that equation.”
- AWS Transform handles IBM z/OS COBOL modernization. AWS says customers are completing full transformation and testing of 250,000-line mainframe applications in six weeks, and that its assessments find an average of 35% in compute and 45% in licensing savings.
- IBM watsonx Code Assistant for Z converts COBOL to Java. IBM Research reports its pipeline delivers a median structural quality score of over 80% and a functional score above 75% on its test set.
So if you’re asking whether AI can convert COBOL to Java, the answer is yes. Notice what IBM’s own numbers say, though: a functional score above 75% means a meaningful share of the converted logic still needs work. That’s where the real project is.
Translation isn’t migration
IBM’s response to the sell-off was self-interested, but it wasn’t wrong. As Rob Thomas, IBM’s SVP of software, wrote: “The modernization challenge is not a COBOL language problem. It is everything the application runs on and integrates with.”
VentureBeat put the IBM view more bluntly, quoting a spokesperson: the real work is “data architecture redesign, runtime replacement, transaction processing integrity, and hardware-accelerated performance.”
In our experience, the hard parts of a mainframe migration are:
- Data. Db2, VSAM, IMS and flat files, with formats and encodings decades old.
- Batch scheduling. Hundreds of jobs with dependencies nobody has fully written down.
- Integrations. Partner feeds, EDI, reports that land in someone’s inbox every morning.
- Business rules nobody remembers. The tax edge case, the month-end exception, the hard-coded store number.
AI helps with all of these, especially the last one. But it doesn’t remove the need to understand them.
How much can leaving the mainframe save?
Real examples, with numbers from the organizations and vendors involved:
- The New York Times moved a COBOL-based system to Java and later to AWS. It now costs 70% less to operate per year than it did on the mainframe in 2015.
- The U.S. Air Force converted 1.3 million lines of COBOL to Java on AWS GovCloud. Per the vendor case study, annual cost went from $30 million to about $3 million.
You don’t have to move everything to start saving. As we covered in what actually sets your z/OS software bill, IBM’s monthly software charges usually follow the busiest four hours of the month. Moving the right batch jobs out of that window can lower the bill well before a full migration.
A mainframe modernization plan that works
This is the approach we use. It’s slower than “convert everything,” and much less likely to fail.
1. Inventory and rank
List every job, what it reads, what it writes and who depends on it. Rank by dollars, meaning share of the cost peak, and by risk. Start where dollars are high and risk is low.
2. Write the spec before the code
For each job you move, write down what it does: inputs, outputs, rules, rounding, edge cases, error handling. AI is very good at drafting this from COBOL source. A person who knows the business has to check it. The spec, not the old code, becomes the source of truth.
3. Let AI do the heavy lifting
Use AI to read the COBOL, draft the spec, generate the new code and write tests. This is where the time savings are real.
4. Verify independently
Build a check that doesn’t come from the same place as the new code, such as a separate model of the spec or reconciliation against real historical outputs. Plant known bugs and make sure your checks catch them.
5. Dual-run
Run the new job alongside the old one every cycle and compare outputs record by record, including month-end and year-end, until they match.
6. Cut over one job at a time
Turn off the old job only after the outputs match and the people downstream sign off. Then do the next one.
When to bring in a mainframe modernization consultant
You probably need outside help if:
- Your COBOL experts are retiring and nobody is shadowing them
- You’ve tried a big-bang migration and it stalled
- You want AI to do the conversion work but don’t have a way to prove the results are right
- Your licensing bill keeps climbing and you don’t know which jobs drive it
How we help
We’re a small, senior team that does AI-assisted COBOL modernization the careful way: spec first, independent verification, dual runs, one job at a time. We work alongside your mainframe team, not around them.
See our mainframe migration services, or book a call to talk through which jobs would save you the most to move first.
