“The whole is more than the sum of its parts.”
– Aristotle (who, to be clear, never had to migrate COBOL)

‍

Here’s a question from my kitchen to yours: why does multiplying a recipe so rarely produce something that tastes as good as the original? The ratios look right on paper. The math is correct. And yet.
‍
Similarly, approaches that use AI to extract business logic from COBOL and rewrite them into microservices architectures are often flavorless, broken facsimiles of what they’re trying to achieve.

The issue isn’t the business logic, it’s everything else that makes that business logic do what it does. For example, COBOL runs inside IMS, DB2, CICS, JCL, and decades of proprietary subsystems that have been constantly co-evolving. Lifting business logic out of this environment is like trying to separate the eggs back out of a baked cake—the bonds have already formed, invisibly, and they don’t come apart cleanly.
‍
Put another way, focusing solely on the business logic neglects the integration logic: the transaction sequencing, timing dependencies, error-handling paths, retry behaviors, and, say, that one inexplicable field that is technically optional but has never, in 30 years of production, actually been null. This isn’t written down in one place. It’s woven into the execution environment itself, impacting how CICS handles a conversation, or how a batch schedule has quietly organized the supply chain since 1987.

There’s also the execution environment to consider (think induction vs gas stoves). For example, a CICS transaction that has always completed in microseconds on the mainframe now has to traverse a network, negotiate eventual consistency, wait its turn. The business logic is identical, but the environment is not; and so, performance suffers.

So how do you modernize a system whose full behavior has never been written down? You can’t do it by reading the code, interviewing the architects, or trusting the documentation, because none of those sources are complete. And certainly you can’t do it by “extracting business logic,” using AI or not.

The system itself as it runs is the only authoritative record of what the system does. Which means the only way to truly understand it is to observe it—exhaustively, under real conditions—before you touch it.

This is why replication must come before rewriting “business logic” into new architectures. And not replication of the code, nor of the business logic, but replication of the behavior—every timing characteristic, every error path, every quirk of that never-null optional field. You cannot know what you’re changing until you know what you’re working with.

Replicate first. Understand what you’ve replicated. Then, and only then, start adjusting the recipe.
‍

News and Views

Margaret Storey writes about the emerging issue of cognitive debt: the accumulated loss of shared understanding about a system’s behavior and design decisions, making it harder for teams to reason about, modify, or extend it. Integration logic : cognitive debt :: business logic : technical debt. The money quote: “velocity without understanding is not sustainable.”

Anthropic published a piece on how AI makes COBOL modernization suddenly a cost-effective proposition, sending IBM stock tanking. But it’s still focused on using AI to understand business logic, when the real challenge is how to reconstruct a modern replica as fast as possible (that’s what we do).

The Economist argues that the effect of AI on productivity is still barely registering, noting, “...improvements are usually made not just when workers use a new tool more often, but when firms reorganise production around it.”

‍

From the Orchard

Our Substack continues to bloom! Rin Kuryloski discusses the mismatch between how agents are used and how they’re governed in her latest article.

Gareth Smith makes his MO Substack debut, arguing that while treating LLMs like compilers is an appealing path to higher abstraction and productivity, real trust in their code must be earned through repeated, test-backed experience—much like with human teammates or traditional compilers—and we’re not fully there yet.


Curious to learn more? Say hello@mechanical-orchard.com.‍

‍

—

View all newsletters here

‍