Legacy Modernization and IP Ownership: What Regulated Enterprises Get Wrong About AI-Assisted COBOL Rebuilds

The Market Is Moving, But Most Estates Are Not

The legacy modernization market is large and growing. According to figures cited by DreamFactory in their legacy modernization statistics report, the market reached $24.98 billion in 2025 - yet McKinsey research cited in the same report found that 70% of Fortune 500 companies still operate software over two decades old. A GAO report cited in that same source found the U.S. government spends roughly 80% of its IT budget maintaining legacy systems.

That gap between market spend and actual estate age tells you something important: money is flowing into modernization programmes, but the core systems are not moving. The reasons are well understood by anyone who has tried. Legacy COBOL is not just old code. It is decades of accumulated business logic, regulatory compliance rules, and edge-case handling that no one fully documented and no one still working at the organisation fully understands.

Why the Anthropic Incident Matters

In February 2026, Anthropic published a blog post claiming that AI could rapidly refactor COBOL. IBM's stock dropped 13% in a single day - its worst single-day fall since October 2000, as reported by CIO.com and DevOps.com. The market reaction was not irrational. IBM's mainframe services business is built substantially on the premise that COBOL modernization is hard, slow, and requires deep specialist expertise.

What the incident actually illustrated was the anxiety and confusion surrounding legacy modernization claims. The Anthropic post was about Claude Code's ability to translate COBOL syntax. But as the DevOps.com analysis made clear, modernizing COBOL is fundamentally about reverse-engineering embedded business logic - not just translating syntax. Those are different problems with different risk profiles.

Syntax translation is tractable. Business logic extraction is not, at least not without a structured approach that produces human-readable, auditable artefacts before a single line of new code is written.

The Two Mistakes Regulated Enterprises Make

Mistake One: Treating It as a Code Translation Problem

Most AI-assisted COBOL modernization tools start with the code and produce new code. That sounds efficient. In practice, it skips the most important step: producing a structured, human-readable representation of what the legacy system actually does.

In regulated industries - financial services, insurance, healthcare, government, telecom - you cannot simply replace a system and assert that it behaves identically. You need to demonstrate it. Auditors, regulators, and change control boards want documented requirements, traceability from those requirements to the new system's behaviour, and evidence that the business rules embedded in the old system are preserved or deliberately changed.

A direct code-to-code translation, however technically accurate, does not produce that evidence. It produces new code. The audit trail that regulators expect under frameworks like SOX, FedRAMP, and HIPAA-style change control does not exist unless you build it deliberately.

Mistake Two: Treating IP and Audit Trail Ownership as a Preference

Publicis Sapient, writing for regulated industry audiences, has noted that for regulated enterprises, modernization is also about knowing where code and data are processed, maintaining auditability, and proving that controls remain intact - and that data sovereignty is rising on the technology agenda, not falling.

This matters because many AI-assisted modernization approaches process your codebase through third-party cloud infrastructure. Your legacy COBOL may contain proprietary pricing logic, actuarial models, fraud detection rules, or government-mandated processing workflows. Sending that codebase to a shared cloud environment raises questions your legal, compliance, and data protection teams will ask - and should ask.

In a regulated enterprise, IP ownership and audit trail ownership are not preferences. They are structural requirements. If you cannot demonstrate that the AI-generated artefacts - requirements, blueprints, work orders, and code - belong to you, and that the process that produced them is traceable and auditable, you have a compliance problem before you have a modernization success.

Why Parallel Operation Is Not Optional

Regulated enterprises cannot freeze their business while a modernization programme runs. A bank's payment processing cannot go dark for six months. An insurer's claims system cannot be taken offline while a rebuild completes. A government agency's benefits platform cannot be suspended pending migration.

This is why the strangler-fig pattern - running the new system in parallel with the existing estate and incrementally cutting over traffic - is not just a technical preference. It is a business and regulatory requirement. Any modernization approach that requires a hard cutover, a moment when the old system stops and the new system starts, is asking you to accept a risk profile that most regulated enterprises simply cannot accept.

Parallel operation also provides the validation environment that regulators expect. You can demonstrate, with live data, that the new system produces identical outputs to the legacy system for the same inputs before any cutover occurs. That evidence is what change control boards and external auditors want to see.

What a Governed COBOL Modernization Actually Looks Like

The right approach starts before any code is written or translated. It starts with the legacy codebase as input and produces structured, human-readable artefacts: requirements that describe what the system does, blueprints that describe how the new system will do it, and work orders that connect the two.

This is the step most AI-assisted tools skip. It is also the step that makes everything else auditable.

At Lumaq, the process is designed around exactly this problem. A legacy codebase is ingested and used to produce requirements, blueprints, and work orders before any new code is generated. The business logic embedded in the old system is extracted and documented in plain language - not just translated into a new programming language. A human approval gate sits between that documentation and any code generation. Nothing moves to production on the basis of AI output alone.

The output - code, IP, models, and the full audit trail - is owned entirely by the customer. No lock-in, no shared infrastructure dependency, no ambiguity about where the data was processed. Lumaq runs on-prem, in a private cloud, or in an air-gapped environment, which means the answer to "where was our codebase processed?" is always "inside our own perimeter."

For a regulated enterprise operating under SOX, FedRAMP, or equivalent frameworks, that is not a feature. It is a baseline requirement.

The Human Approval Gate Is a Compliance Control, Not a Slowdown

There is a tendency in AI-assisted development conversations to treat human review as friction. In regulated industries, it is the opposite. The human approval gate is what makes the process defensible.

When a regulator or auditor asks how a change was approved, "an AI agent decided it was ready" is not an acceptable answer. "A qualified engineer reviewed the requirements, approved the blueprint, and signed off on the work order before code was generated" is. The audit trail Lumaq produces supports exactly that narrative, because every step is traceable from the original legacy codebase through to the production-ready output.

This is also why the separation between AI-generated artefacts and the human approval decision matters. The AI handles the volume and speed of analysis. The human handles the accountability. Those are different roles, and conflating them is how regulated enterprises end up with modernization programmes that cannot survive regulatory scrutiny.

What to Ask Before You Start

When evaluating AI-assisted COBOL modernization approaches, the questions that matter most are not about speed or cost. They are about governance and ownership.

• Does the process produce documented requirements and blueprints before generating code, or does it go directly from old code to new code?
• Who owns the artefacts produced during the process - including the intermediate documentation, not just the final code?
• Where is the legacy codebase processed, and does that environment meet your data sovereignty requirements?
• Is there a mandatory human approval gate before anything reaches production, and is that gate documented in the audit trail?
• Can the system run entirely within your own environment - on-prem, in a private VPC, or air-gapped - without dependency on shared cloud infrastructure?
• Does the modernization approach support parallel operation with the existing estate, or does it require a hard cutover?

If an approach cannot answer all six questions clearly, it is not ready for a regulated enterprise environment.

Conclusion

COBOL modernization is not a syntax problem. It is a business logic extraction problem, an audit trail problem, and an IP ownership problem. AI can help with all three - but only if the approach is built around governance from the start, not retrofitted at the end.

The enterprises that succeed in 2026 will be the ones that treat the audit trail and IP ownership as structural requirements, not afterthoughts, and that choose modernization approaches designed for that reality from day one.

If your organisation is ready to have that conversation, book a scoping call at lumaq.ai.

Frequently Asked Questions