Your legacy code is the asset. Stop trying to replace it.

On the 23rd of February, IBM had its worst day on the stock market since 2000. The shares fell nearly thirteen percent, closing at 223.35 dollars, with roughly thirty billion knocked off the company’s value in a single session. The trigger was Anthropic positioning Claude Code for the discovery and documentation work inside COBOL modernisation, reading whole mainframe codebases, mapping dependencies, and surfacing the implicit couplings that take human analysts months to find.

The market read that as a death sentence for the mainframe business. I’m not convinced.

Anthropic made comprehension of legacy code cheap. The sell-off treated comprehension as if it were replacement. Those are not the same thing, and the gap between them is the most important thing a business running twenty-year-old code needs to understand this year. Comprehension is cheap now. Correctness still is not.

The repricing

Reading a legacy system and rewriting one used to cost roughly the same. Now they are priced completely differently, and the modernisation conversation has not caught up.

An agent can map a codebase nobody has fully understood in a decade, in an afternoon, for pennies. Getting the payments code, the settlement logic, the regulatory reporting, and the approval chains right every single time is still expensive. Those two numbers used to sit next to each other on the same estimate. Pull them apart and the whole decision changes.

The twenty percent of a legacy system that AI cannot safely rewrite is exactly the twenty percent that justified building the system in the first place. The edge cases that took weeks of legal review. The compliance logic that survived three audits and a regulatory change. The approval chains worked out by people who actually understood the business. That is not the part you hand to a model and hope.

The failure data is brutal on this point. Most big-bang rewrites fail at enterprise scale. The TSB core-banking migration left a bank unable to trade for days and cost somewhere around 330 million pounds. A 41 million dollar COBOL-to-Java migration was abandoned at forty percent complete after fifty-two months of work. Comprehension would not have saved any of them. They did not fail because nobody understood the old system. They failed because rewriting business-critical logic and getting it right every time is genuinely hard, and reading the code was never the bottleneck.

There is a real counterargument here, and it has a credible champion. IBM’s own watsonx Code Assistant for Z does agentic, selective COBOL-to-Java translation, it runs on-premises now, and it gets better with every release. AI-assisted rewriting is real, and we are wholehearted proponents of agentic coding.

So look at the number. The best automated conversion tooling lands somewhere in the seventy to eighty-five percent range. For the bulk of a codebase, the screens, the boilerplate, the reporting, that is a genuine productivity win. For the slice that has to be right every single time, it is a disqualifying figure. Wrapping is not an argument against rewriting anything. It is an argument about which twenty percent you refuse to gamble on.

The asset was never the interface

Here is the thing the sell-off missed, and most modernisation programmes miss it too. A legacy system is not one thing. It is two, valuable logic wrapped in an interface, and they should not be treated the same.

The logic is the asset. The rules, the validations, the workflows, the decades of hard-won decisions sitting in the code. The interface is just how you reach that logic. The screens, the menus, the integration points. And interfaces were always disposable. We replaced green-screen terminals with web apps without anyone calling it a rewrite, because the rules underneath never moved.

So the move on a legacy system is not to rewrite the asset. It is to keep the asset and give it a better way in. An agent is the best new interface you can put in front of decades of business logic. The question stops being whether to rewrite. It becomes what the agent is allowed to touch, and how tightly you control it.

That control is the whole game, and how tight it needs to be depends entirely on what the logic underneath can do.

Replace the door, keep the rules

Our analytics platform let customers build dashboards through a designer with hundreds of options spread across dozens of screens. It was a desktop application, dated, and complicated to use. That designer was not the asset. The asset was the capability in the cloud platform underneath it. The way the data is organised, the speed it comes back at, the security model that governs every request, the ability to shape data on the fly. None of that was the problem.

So we replaced the door. Studio is our agentic dashboard builder, and it does the job the old designer did. Instead of clicking through screens, someone says build me a sales dashboard for the north region this quarter, and Studio builds it against the same data, with the same security. The value did not come from rebuilding the analytics capability. It came from changing how you reach it.

We made that call with a clear conscience because the designer was the obvious liability, not the asset. It was dated, it was hard to use, and it was the most obvious place in our products to put an agentic front end and get an immediate improvement. The capability it guarded was fine. The way in was the problem.

That is the test, said out loud. Is the legacy the asset or the liability? When the value is in the rules, keep them and put an agent in front of them. When the value is in the backend and the front end is just a dated way in, replace the door and keep the rules. This is not a rule that says never replace anything. It is a rule about what you replace. When the logic is right and the only risk is in disturbing it, you keep it.

When the door opens onto something dangerous

Studio is forgiving. The worst an agent can do is build a dashboard nobody wants. Most legacy systems are not that forgiving, because the logic the agent reaches is operational. It moves money, changes records, takes action. An agentic door onto that is a different problem, and it is where the discipline earns its keep.

We are building an expert system for a database engineering client. Underneath it sits a mature, well-engineered monitoring platform that has spent years surfacing metrics and alerts about production databases. That platform is the asset. We did not touch it. We put an agentic front end on it so an engineer can ask what is happening on this database right now, in plain language, instead of navigating to find out.

At the moment the system is read-only. That is the easy boundary. The sharper question is what happens when you need the agent to act, to take steps that maintain a database rather than just report on it. That is the path we are building now, and we are building it carefully, because an agent that does the wrong thing to a production database can be catastrophic. Trust here is earned in stages, not handed over on day one.

The shape of it is this. The agent never executes anything. It can only request that a command runs. The decision to run it is made in the application, not in the model, and the command has to come from a predefined dictionary. The agent cannot invent an operation, it can only ask for one that already exists. Every command in that dictionary carries a trust level. The benign ones, the ones that cannot do harm, run on the agent’s request. Anything that can do harm needs explicit permission from an authenticated user with the authority to grant it. The model asks. The application decides. A human stands in front of anything that matters.

This is not new discipline. It is approved procedures that enforce the existing rules, the same pattern that has protected production systems for decades, with an agent in the requester’s seat instead of a user. If you’re an OpenEdge developer, Progress shipped the same pattern this quarter with its OpenEdge MCP Server, agents calling approved procedures rather than bypassing the business logic to reach the data underneath. EVP at Progress, John Ainsworth, articulated this as bluntly as we would, that an agent able to rewrite rows in your production ERP off a hallucinated update is a problem no amount of vector search will save you from.

The judgement you cannot outsource

Building the door is not the hard bit. The tooling for that has turned into commodity infrastructure in the space of a few months. Progress is one example, with its OpenEdge MCP Server, and it is far from alone. Salesforce used its developer conference in April to make the whole of the largest CRM in the world callable by agents, sixty new MCP tools that expose the platform’s logic instead of its screens. In the run-up to its Summit in late May, Snowflake acquired Natoma to ship an MCP gateway, the connective layer that lets agents reach enterprise systems without bespoke integration. The biggest names in enterprise software all reached the same conclusion in the same quarter. The plumbing is becoming commodity.

The judgement is not. Deciding which existing procedures are safe to expose as agent tools, and which stay locked, is the work. It is the new senior-engineer skill, and it is the one thing in this whole exercise that cannot be handed to the model that wants to call them. The model will happily ask for the procedure that moves money. Knowing why it must never have it is your job, and it depends on understanding what the business logic actually does, not just what the syntax says.

Years against weeks

The economics argument here is stark. A partner of ours rebuilt off OpenEdge using automated tooling, and it was still a multi-year programme, complex and expensive. The reading was never what made it long. The rewriting was. Standing up an MCP connector and an agentic front end over that same kind of estate is a matter of weeks. Years against weeks, and the years buy you a fresh rewrite of rules that already worked.

And the platform underneath is not dying, whatever the February session implied. Progress grew software licence revenue sixteen percent last quarter, led by OpenEdge. That is a growing legacy, not a dead one. The thing the market wrote off is selling more licences.

Knowing which is which

Modern AI makes comprehension cheap. Correctness is still expensive. Build your modernisation strategy on that last sentence and most of the decisions make themselves.

Spend where the value moved. Interfaces are cheap. Replace them when they are tired, and let an agent be the replacement. We built Studio for exactly that reason.

Business logic is the expensive part, the painful part, the part that breaks banks when you get it wrong. Do not re-engineer it unless the rules themselves are wrong. Keep it, put an agent in front of it, constrain that agent to vetted paths, and keep a human ahead of anything that writes.

Agents should replace interfaces. Business logic generated over decades is your biggest asset, agents should call it, and obey it.