$31 billion in a day: what the market told IBM

When I saw the news on Monday, my first thought was about three clients of ours who’ve been debating whether to migrate their mainframe for years. The conversation always ended the same way: “the numbers don’t work.”

That same Monday, IBM lost 13.2% of its market value — the worst day for the stock since 2000. Over $31 billion in market cap vanished in a single session. It wasn’t a bad quarter, a corporate scandal, or a macroeconomic crisis.

It was a blog post.

Anthropic published a technical article showing how Claude Code can automate COBOL code modernization. The market read between the lines: if AI can do what IBM charges millions for, IBM’s business model has a problem.

According to CNBC, the stock is down 27% over the past month — the worst monthly slide since at least 1968. Tom’s Hardware reported it was the largest single-day percentage drop in over two decades.

The market isn’t telling IBM that COBOL is going away tomorrow. It’s telling IBM that the monopoly on COBOL modernization has an expiration date.

COBOL: 67 years old and still processing 95% of ATM transactions

To understand why this matters, you need to understand the scale of what’s at stake.

According to Anthropic’s blog, 95% of US ATM transactions still run through COBOL code. Hundreds of billions of lines in production worldwide. Banking systems, insurance companies, governments, supply chains. The infrastructure that moves the real economy runs on a language created in 1959.

The talent pool is drying up. COBOL is taught at a handful of universities. The engineers who wrote these systems are retiring, and every year the gap between production code and the people who understand it grows wider.

Why don’t companies migrate? Not for lack of will. The reason is economic: understanding legacy code costs more than rewriting it. A 30-year-old COBOL system has undocumented dependencies, business flows that nobody remembers designing, and logic buried across thousands of files that interact in ways only the original system “knows.”

Mapping all of that required armies of specialized consultants. That’s where IBM found its goldmine. Mainframe consulting was a profit center for them, a cost center for their customers. The more complex and opaque the system, the more dependent the customer was on IBM for any change.

That model worked for decades. Until now.

What Anthropic proved (and what it didn’t)

Anthropic’s blog doesn’t show a system that rewrites COBOL automatically. What it shows is something more subtle and, in my view, more dangerous for IBM.

Claude Code can map dependencies in COBOL code: understand which program calls which, where data flows, and which modules are dead code. It can also document forgotten workflows — those processes that nobody in the current organization designed but that keep running because nobody dares touch them. Perhaps most valuable for the initial assessment, it identifies hidden data flows that would be invisible without weeks of manual analysis.

The methodology has four phases: discovery, risk analysis, strategic planning, and incremental implementation. Not different from what any consulting firm would propose. The difference is who does the most expensive phase.

Discovery (mapping what you have, how it connects, what risks exist) is where most of the budget goes in any legacy modernization project. Reading thousands of files, tracing calls between modules, reconstructing business logic that nobody remembers — all of that consumed the bulk of consulting budgets. AI processes those volumes of code in a timeframe no human team can match.

Now, what AI does not do: replace human judgment on business priorities, regulatory compliance, or the right migration sequence. Deciding what to migrate first, what can wait, and how to keep the system running during the transition requires experience and business knowledge that no model has.

If you’re already familiar with the Strangler Fig pattern for incremental migration, what Anthropic is proposing is that the preceding stage, the mapping, stops being the bottleneck.

Why the market reacted so violently

IBM’s drop wasn’t a reaction to AI-generated code. It was a reaction to something Wall Street understands better than anyone: someone just made your most profitable product cheaper.

COBOL consulting was recurring revenue for IBM because the barrier to entry was high. Not just anyone could sit in front of a mainframe with a million lines of COBOL and understand what was happening. It required years of experience, knowledge of the specific hardware, and familiarity with the client’s particularities. IBM had that. Their clients didn’t.

That knowledge asymmetry was the basis of their pricing. You didn’t charge for lines of code analyzed; you charged for being the only one who could do it.

When the cost of understanding COBOL drops from “millions in consulting” to “AI tool + engineers who guide the process,” IBM’s value proposition gets questioned. Not because IBM stops knowing about mainframes (they still know more than anyone), but because their clients are no longer forced to pay only IBM to understand their own systems.

At IQ Source, we’ve seen something similar with clients who depended on a single ERP vendor for any change to their system. For years they paid whatever was asked because there was no realistic alternative. When one appeared, the vendor’s margins compressed within months.

IBM is in a giant version of that same situation.

What your company should do if it runs mainframe systems

If your company operates on COBOL or any mainframe system, this moment is an opportunity. Exploration costs just dropped, and that changes which projects are viable.

The first step is knowing what you have. Sounds obvious, but most companies with mainframes don’t know exactly what code is in production, what percentage is dead code, and what dependencies exist between modules. With AI, that mapping that used to take months of consulting can be completed in weeks. It’s not perfect (you need engineers to validate the results), but it gives you a baseline that was previously too expensive to obtain.

Then comes the hard question: what stays and what moves? Not all COBOL needs replacing. Some modules work well, are stable, and cost more to migrate than they’re worth. For those, the right call is to leave them in place and build integration layers around them. Others depend on talent that’s retiring, and there the migration is urgent.

Did you evaluate a modernization project two years ago and the numbers didn’t work? Worth redoing the math. The analysis phase, always the most expensive component, now costs a fraction of what it used to. General enterprise AI costs have also dropped, which changes the entire equation.

And one piece of advice we give every client in this situation: before migrating anything, put APIs in front of your legacy systems. That lets old and new coexist, reduces risk at each phase, and gives you flexibility to prioritize what moves first. A well-designed API strategy is what separates a controlled migration from a project that blows its budget.

COBOL consulting will never be the same

IBM’s drop isn’t a one-off anomaly. The market is pricing in a structural change in how enterprises will approach their legacy systems from here on out.

COBOL isn’t going away tomorrow. Or in five years. Global financial infrastructure depends on it, and replacing it is measured in decades, not quarters. But the power dynamic has shifted, and that’s not going back. Companies running mainframes are no longer captive to a single vendor’s pricing to understand what they have and plan what to do with it.

For companies in Latin America, there’s an angle few are discussing. Mainframe modernization has always been dominated by consultancies charging North American rates. When the most expensive phase of the process gets cheaper, projects that used to get killed in the first budget meeting become viable. This changes the conversation for many companies in the region that knew they had a problem but couldn’t afford the solution.

At IQ Source, we work with companies that run legacy systems and want to understand their real options, not the ones sold by the vendor that benefits from them staying put. If your company has COBOL or mainframe code and wants to know what it has, what can move, and what it would cost, we can run a diagnostic on your legacy infrastructure: map dependencies, document critical flows, and deliver a migration plan with real costs and timelines. Let’s talk about your case.