5 Legacy Codebases AI Can Now Modernize and Let You Own

Using AI to modernize legacy code works because AI coding agents are now good at the expensive part: reading and understanding old, undocumented systems, not just writing new ones. That shift changes the math on whether you rewrite, replace with SaaS, or finally own the system you already have.

The real barrier was never the code. It was understanding it.

For forty years, legacy modernization meant hiring consultants to reverse-engineer a system before anyone could touch it. The code was rarely the hard part. The hard part was that the person who understood it retired in 2011, the documentation was wrong or missing, and nobody wanted to be the one who broke a payroll run or an ATM network by guessing.

That's why so many companies gave up and bought a SaaS replacement instead, or paid for a multi-year rewrite and hoped. Anthropic put it plainly when describing the old approach to COBOL: "Modernizing a COBOL system once required armies of consultants spending years mapping workflows."¹

What's changed is that AI agents can now do that mapping and documentation work themselves, cheaply, on code nobody currently understands. That's the actual breakthrough, and it's why the five examples below aren't a random tour of retro computing. They're proof that the discovery problem, the thing that made modernization expensive, is being automated at every scale from a hobbyist's 68000 assembly to a bank's mainframe.

1993 Amiga assembly: a 68000 game rebuilt for Godot by an AI that read the raw hardware code

In 1993, a developer in Baghdad built a game called Babylonian Twins on an Amiga 500, writing directly in 68000 assembly with no modern tooling and no surviving documentation beyond his own memory.² Thirty-three years later, he fed that raw assembly to Claude Code and asked it to port the game to Godot.

The AI read the file formats and the hardware-level assembly cold, made its own calls about how to carry thirty-year-old logic into a modern engine, and shipped a working port to iOS and Android, with a Steam release planned.² The developer's own words: "it went faster than I could follow."²

Compare that to the last time this game got ported. In 2010, a team spent months of nights and weekends hand-writing roughly 34,000 lines of C++ to bring the same game to iPhone.² That's the delta. Not a small productivity bump. A different category of effort.

Can AI revive a dead multiplayer world with no surviving documentation?

Game developer Jon Radoff had 333 script files written in a custom scripting language from a 1990s multiplayer game.³ No documentation survived. No one who wrote the language was still around to ask. Most consultants would have quoted a year just to scope the job.

He gave the raw files to Claude and told it to figure out what the language did and rebuild the game.³ Six weeks later he had a live engine: 2,200 rooms, 2,000 items, 300 monsters, 60 spells, and a full combat system.³ Claude reverse-engineered an entire proprietary programming language from nothing but its output, then used that understanding to reconstruct the runtime.

Same pattern as the Amiga case, just applied to a language instead of a chip architecture. AI doesn't need a spec. It needs enough examples to infer one, and it can do that inference far faster than a human archaeologist working file by file.

40-year-old C64 games: decompiling 6502 binaries back into readable, cross-compilable source

The pattern holds for commercial software too, not just personal side projects. Researchers used Claude to reverse-engineer Rigel's Revenge, a 1987 Commodore 64 text adventure, by building a full 6502 CPU emulator and decompressing the game's custom SMART EGG text-compression engine.⁴

They hit a real wall along the way: a 256-byte token table that only existed at runtime, never stored anywhere retrievable in the binary.⁴ They found it anyway, then documented the game's internals and cross-compiled a working modern version.⁴ That's decompilation, format recovery, and preservation done on a 40-year-old binary with no source code and no comments, by an AI that had never seen the game before.

The lesson for anyone sitting on an old commercial binary with no build environment left: missing source code is no longer a dead end.

COBOL mainframes: the 220-billion-line core of banking, insurance, and government

This is where the stakes, and the dollar figures, get serious. COBOL still runs an estimated 95% of ATM transactions in the US and underpins core systems across banking, aviation, and government.⁵ GitHub puts the installed base at roughly 200 billion lines still running today.⁶

In February 2026, Anthropic published a framework claiming Claude Code could automate the exploration and analysis phases of COBOL modernization, the part that historically ate most of a consulting engagement's time and budget.¹ The market reaction was immediate: IBM's stock dropped 13.2% in a single day, its steepest daily decline since October 2000.¹ That's not a hobbyist blog post moving markets. That's Wall Street pricing in a real threat to legacy-modernization consulting revenue.

IBM pushed back, and the pushback is worth taking seriously. Rob Thomas argued that "translating code is one thing. Modernizing a platform is something else entirely," pointing out that enterprise COBOL runs inside a vertically integrated stack of z/OS, CICS, IMS, Db2, RACF, and MQ, and that the resilience enterprises actually pay for comes from that platform, not the language.⁷ Code translation alone doesn't capture most of what makes these systems hard.

Anthropic's own framing is more measured than the headline suggests. It positions AI as automating exploration, dependency mapping, and risk analysis, the expensive discovery work, while keeping strategic planning, regulatory judgment, and final validation with human COBOL engineers acting as safety officers.⁸ That's a meaningfully narrower claim than "AI replaces the mainframe team," and it's the honest one.

Why won't companies modernize the aging internal system nobody wants to touch?

Most companies don't run COBOL. They run something almost as unloved: a VB6 order system, a Delphi inventory tool, a .NET Framework app three versions behind, an AngularJS front end nobody's touched since 2017. It works, technically, which is exactly the problem. Half of IT professionals cite "the system still works" as the top reason modernization keeps getting delayed, even as the costs pile up.⁹

And the costs are real. US technical debt is estimated to cost the economy $2.41 trillion a year, over 10% of GDP, with $1.52 trillion of that tied specifically to accumulated technical debt per CISQ's 2022 analysis.⁹ Federal agencies alone spend over $100 billion a year on IT, and 80% of that just keeps existing legacy systems running rather than improving anything.⁹ Sixty-two percent of US organizations still rely on legacy software in daily operations, and 92% of leaders admit to carrying some form of technical debt right now.⁹

GitHub documents a practical three-step framework a Microsoft engineer used to modernize COBOL systems without ever learning COBOL herself: reverse-engineer legacy files into markdown documentation, enrich the code's rigid structure so AI agents can parse it, then orchestrate specialized agents for call-chain mapping, test generation, and conversion.⁶ The same playbook applies to a VB6 app or an ERP customization just as well as it does to a mainframe. GitHub's own cost estimate for AI-assisted analysis lands around $2 to $5 per 1,000 lines, a fraction of a consulting day rate.⁶

This is where Build vs Buy gets interesting again. If understanding your own legacy system now costs a few dollars per thousand lines instead of a six-figure discovery engagement, the case for renting a SaaS replacement to escape your own codebase weakens. You already paid for that software once. Owning it, instead of throwing it out, is now cheaper than it's been in decades, part of the same ownership renaissance reshaping how technical teams think about their stacks.

What AI still can't do

None of this means point the agent at the repo and walk away. GitHub is explicit about this: "Everyone who's currently promising you, 'hey, I can solve all your mainframe problems with just one click' is lying to you," and full end-to-end automation is likely five or more years out.⁶

The governance risk is specific, not vague. Research cited by Werner Heijstek found that AI-generated code often contains more security vulnerabilities and gets merged into critical systems with very little formal review, calling this "a governance problem, not a tooling problem."⁸ He adds a sharper point: "Senior developers become more productive. Junior developers don't magically become seniors."⁸ AI collapses the discovery cost. It doesn't hand a junior engineer the judgment to sign off on a bank's core ledger logic.

IBM's stack argument matters here too. Even a perfect line-by-line translation of COBOL to Java doesn't replicate the guarantees of z/OS, CICS, and RACF running underneath it.⁷ Modernization is still a systems problem, not just a code problem, and every one of the five examples above still needed a human checking the output against reality, whether that's a game that needs to play the same or a bank transaction that needs to actually clear.

How do you start modernizing your own legacy codebase this quarter?

You don't need a mainframe or a MUD to apply this. If you're carrying an old internal system that a SaaS vendor keeps pitching you a replacement for, the sequence is roughly the same across every example in this piece:

1. Pick one bounded module, not the whole system. The Amiga port and the MUD revival both worked because someone scoped a complete, self-contained piece rather than trying to swallow the entire codebase at once.²³
2. Let AI produce documentation before it touches code. GitHub's framework starts with reverse-engineering files into markdown docs specifically so a human can review the AI's understanding before any conversion happens.⁶
3. Build the test harness before you migrate anything. The C64 decompilation project only trusted its recovered token table once it could cross-compile and verify behavior against the original.⁴ Do the same before you cut over anything that touches money or customer data.
4. Keep a human as the safety officer, not a rubber stamp. Anthropic's own framing puts final validation and regulatory judgment on human engineers, not the agent.⁸ That checkpoint isn't optional, especially anywhere compliance or financial reporting touches the code.
5. Treat the output as an asset, not a one-time project. The whole point of owning your software instead of renting a SaaS replacement is that you keep the thing you modernized. Document it, version it, and maintain it the way you'd maintain any capital asset, because that's what it now is.

If you're already running your own agents to do this kind of discovery work, it's worth thinking about where those agents actually run. A modernization project means feeding an AI your most sensitive, undocumented internal code, and running that inference on infrastructure you control is a meaningfully different risk profile than piping thirty years of proprietary business logic through someone else's API. It's the same logic behind why teams are moving inference workloads onto hardware they own, and the same reason a vendor that can quietly change terms on your software is a liability you don't want anywhere near your core ledger.

The barrier that kept legacy systems frozen in place for decades wasn't the age of the code. It was the cost of understanding it well enough to trust it. That cost just fell by an order of magnitude, and it's not coming back up.