AI-First
Can you modernise legacy code with Claude Code? Yes, as long as you treat the model as a fast executor whose every output has to be proven by a test, not as an architect whose word you take on trust. Claude Code is Anthropic's coding agent. It reads a repository, makes a plan, edits the files and runs the builds itself. On COBOL, VBA or old Java, the public demos are convincing. The documented mistakes are just as convincing.
- 📊 Documentation first, Claude makes code that nobody understands any more readable before any migration starts.
- ⚠️ Six mistakes logged, a wrong count, an inaccurate plan, a decision it had no right to make: none of them reached a commit.
- ✅ Proof through tests, you demonstrate that behaviour is equivalent, you don't just declare it.
- 🚀 Start small, an Excel macro or an isolated module before any mainframe.
I train SMEs to use Claude Code, and the same question comes up every time: "We have an old system nobody dares touch. Can AI get us out of it?" My answer fits in one sentence: AI lowers the cost of understanding and rewriting, not the cost of verifying. Here is what the sources show, and where I draw the line.
Why is legacy code so expensive to modernise?
Legacy code is expensive because its business logic isn't written down anywhere. It lives in the code, and the people who wrote it have left. Understanding what the system does often costs more than rewriting it, as Anthropic's webinar "Modernizing Legacy Code with Claude Code" (anthropic.com) puts it.
How big is the problem?
According to an article on juteq.ca citing a Business Wire report, 74% of modernisation initiatives fail. The same piece, drawing on a McKinsey study, says developers spend an average of 17.3 hours a week on technical debt and maintenance. I'm quoting these figures as their authors give them, without having been able to trace the original studies.
At Thoughtworks, a major car manufacturer had 15 million lines of COBOL to deal with. Two specialists needed about six weeks to take over a single 10,000-line module. The bottleneck wasn't typing code. It was understanding it.
The real cost of legacy is lost knowledge.
Why is AI going after this particular problem?
Because reading large amounts of undocumented code and pulling business rules out of it is exactly what an agent does well. The "Code modernization" page on claude.com lists the target uses: dependency maps, dead code detection, and generating regression tests and documentation from code that had neither.
On Reddit, a thread on r/TechnologyNewsIndia claims Claude translates COBOL into Java or Python with "90% accuracy". That's the poster's own claim, with no method described, and I don't treat it as a reliable figure. The thread does point out that testing and deployment still need heavy human oversight, which the rest of this article bears out.
How does Claude Code document and migrate old COBOL?
In Anthropic's published demo, Claude Code first documents the COBOL program, then migrates it to Java 17 and compares the results against the original. The test bed is AWS's mainframe modernisation demo repository: a credit card system of around 100 files with no documentation.
What happens in the discovery phase?
A specialised "COBOL documentation" sub-agent is created with its own context window, so it doesn't clutter the main conversation. Claude builds a task list covering all 94 files so none gets skipped or handled twice. It produces two memory files (a catalogue that maps cryptic names such as CBAC04C to business roles, and a dependency file), then Mermaid diagrams of the daily batch processing.
The stated result: more than 100 pages of documentation in an hour of continuous running. Anthropic adds that Claude Code can run autonomously for more than 30 hours.
How is the migration kept in check?
Claude switches to plan mode, so no files are modified, and proposes a five-phase plan for the interest calculation function: project structure, data models as Java classes, an I/O layer compatible with the original formats, business logic, and a dual test harness. That harness runs GnuCOBOL 3.2.0 for the original and Java 17 for the new version side by side.
The check covers intermediate calculations, not just final results, and Anthropic claims "bit-for-bit" fidelity. Let's keep some perspective: this is a demo application, far smaller than a real banking system.
A thread on r/ClaudeWorkflows describes the same approach at a larger scale with the GitGalaxy project: GnuCOBOL as the test oracle, "golden master" tests that block the CI pipeline, and a fresh agent per problem with handover notes to prevent drift. Two independent sources land on the same pattern: the old program judges the new one.
What mistakes does Claude make on existing code?
Claude makes plausible mistakes, which is what makes them dangerous, and the difference comes down to the guardrails that catch them. The Legacy to Latest channel replayed real sessions on ShipTrack, a parcel-tracking REST API, upgrading it from Java 11 and Spring Boot 2.7 to Spring Boot 4.1 and Java 25. It took about 2 hours of agent time, cost about $24 at API rates, and finished with 47 passing tests.
What were the six mistakes, and what stopped them?
The table below covers the ones the video goes into.
| Claude's mistake | What exposed it | Lesson |
|---|---|---|
| Reports 56 passing tests when there are 47 | The Maven build output | A summary describes the work, it doesn't prove it |
| Two false claims in the Spring Boot 3.5 plan | The configuration metadata in the JARs | Review a plan like a pull request |
| Picks option B of an API change on its own | Reading the transcript, plus the reviewer sub-agent | Product decisions stay with humans |
| API contract changed despite green tests | Comparing old and new version responses | A test only protects what it asserts |
| Wrong root cause: a renamed configuration key | One command against the metadata | Check before writing workaround code |
SOURCE: Legacy to Latest, YouTube video · UPDATED 10/2026
The sixth mistake was a check that masked a broken build: the first build wasn't clean, so stale compiled classes were still sitting in the target folder. The transcript I had stops before the end of that section, so I'll leave it at that.
Why did the third mistake stick with me most?
Because it's partly the humans' fault. Claude had laid out two options and asked for a decision. But the team's stop hook didn't allow it to stop while the build was red, so Claude made the choice itself and flagged it.
The reasoning was sound. The decision just wasn't Claude's to make. The fix was to allow stopping when only the characterisation tests fail: at that point, red means behaviour has changed, and that's a question for a human.
This matches my core belief: AI should augment the team, not create chaos, and human control stays at the centre. If you want to see how I set up these guardrails for non-developers, read Claude Code without compromise for my SME clients.
What about SMEs: where should you start?
An SME almost never has a 15-million-line mainframe. It has an Excel macro, an Access tool, a script only one employee understands. For that situation, the most telling demo is the smallest one: the Hay Kel channel converts a VBA travel expense form into a Python app with a custom Tkinter interface, then compiles it into a standalone .exe with PyInstaller.
What does the VBA-to-Python demo prove?
It proves that a tool locked inside Excel can become a standalone program in a single session. The test is simple: 100 km in the "compact" category comes to $50, matching the original VBA code. One test case is thin, but the idea of running old and new on the same inputs is the right one.
On r/devsarg, a developer describes turning a VB6 and Access system into a FastAPI and SQLite engine that exposes 59 tools via MCP. Their design rule: the model never touches the SQL, and the backend validates, executes and audits. It's the same philosophy as ShipTrack, with the responsibility sitting in the software.
How do you get started without taking risks?
Here's the sequence I recommend, based on what these sources have in common:
- Document before you touch anything. Ask Claude Code to describe the system and its dependencies, and have someone who knows the business review it.
- Write characterisation tests for the current behaviour, including the odd edge cases.
- Migrate one isolated module in plan mode, with the plan reviewed like a pull request.
- Compare old and new on the same inputs, field by field.
- Keep product decisions with a human.
A useful audit leads to a roadmap, not an 18-month megaproject. For setting up that technical framework with a senior team, the GoLive Software team covers the development side. And for the budget of regular use, see the real budget of my automations with Claude Code.
Should you go for it, and what's my verdict?
Yes, for documentation and for migrating isolated modules, with one non-negotiable condition: a test harness that compares old behaviour with new. Proof comes from the build and from real responses, never from the agent's summary.
What I don't recommend is handing an entire critical system to a session with no test oracle. ShipTrack's $24 and 2 hours make an attractive result, but six mistakes along the way are a reminder that speed without control produces technical debt faster than ever.
There's a market signal too: a thread on r/singularity reports that IBM shares reportedly fell 10% after a Claude Code tool for COBOL was launched. I'm citing that as a reported market reaction, not as analysis. My takeaway for an SME leader: the cost of understanding an old system is dropping sharply, so the cost of doing nothing is becoming easier to see.
Frequently asked questions
Can Claude Code really convert COBOL to Java?
Yes, in the public demos. Anthropic shows an interest calculation program being migrated to Java 17, checked against GnuCOBOL 3.2.0 with claimed bit-for-bit fidelity. That's a demo repository of about a hundred files, not a full production system.
How much does a framework migration with Claude Code cost?
In the ShipTrack case covered by the Legacy to Latest channel, upgrading from Java 11 and Spring Boot 2.7 to Spring Boot 4.1 and Java 25 took about 2 hours of agent time and cost about $24 at API rates. That figure applies to a small demo service, not an enterprise application.
How do you make sure migrated code behaves like the old code?
Run the old and new code on the same inputs and compare the real outputs, including extra fields and date formats. Green tests aren't enough: on ShipTrack, two public API changes got through with every test passing.
Can a non-developer modernise a VBA macro with Claude?
Yes, for a small tool. The Hay Kel channel's demo converts a VBA form into a Python app compiled to an .exe. You then need to test it with real cases and have someone who knows the business calculation review the result.
Should you replace your maintenance provider with AI?
No, not wholesale. AI speeds up documentation and rewriting, but validation, product decisions and security stay human. A senior developer equipped with Claude Code beats either one on their own.
Vidéos YouTube
- Claude Code modernizes a legacy COBOL codebase — Anthropic
- Claude Code Made 6 Mistakes on Legacy Code. None Reached a Commit. — Legacy to Latest
- Convert VBA UserForm to Python App (.EXE) with Claude AI — Hay Kel
- How AI accelerated mainframe modernization – A Thoughtworks COBOL modernization case study — Thoughtworks
Discussions Reddit
- IBM is the latest company victim of Anthropic — r/singularity
- Anthropic's Claude starts rewriting COBOL code — r/TechnologyNewsIndia
- De un sistema legacy en VB6 + Access a un motor comercial open-source — r/devsarg
- Advanced Workflow: Ensuring Code Equivalence in AI-Driven Legacy Modernization — r/ClaudeWorkflows