Legacy or Heritage? Rethinking Technical Debt in Insurance Modernization

Insurance carriers often label aging applications as technical debt, but some systems contain decades of underwriting, claims, actuarial and regulatory expertise that remain critical to the business. Understanding the difference between legacy and heritage applications can help organizations reduce modernization risk and preserve institutional knowledge.

Generative AI has made it fashionable to describe almost anything running on the mainframe as “technical debt” — a liability to be paid down as fast as tooling allows.

For an insurance carrier, that language is dangerous. Not because the mainframe is beyond criticism, but because “technical debt” flattens two very different categories of code into one and prescribes the same treatment for both: get rid of it, as fast as possible.

This is one of the more consequential mistakes in mainframe strategy today, and it follows directly from the argument in the first article in this series related to the April 2026 Gartner research titled “Too Big to Fail: Why Mainframe Exit Projects Are Likely to Fail in the Age of Generative AI”: exit is an outcome available to some workloads, not a strategy for the whole estate.

Workload intelligence only works as a discipline if executives have a concrete filter for telling workloads apart. That filter starts with a simple distinction: legacy versus heritage. The two kinds of “old.”

Not all long-running mainframe code is the same kind of asset; treating it as though it is leads carriers to either over-invest in preserving what should be retired, or discard what the business quietly depends on. To avoid that, it helps to separate the estate into two categories:

• Legacy applications are costly to run, rigid to change and poorly matched to current business needs. They duplicate functionality available elsewhere, exist because no one has had the mandate to retire them or persist purely out of institutional inertia. These are genuine candidates for retirement or replacement, and modernization dollars spent preserving them are largely wasted.
• Heritage applications are old by the same measure of age, but they encode differentiated business capability the enterprise still depends on — actuarial rules, underwriting logic, claims adjudication logic, billing history and regulatory logic built up and refined over decades. Age isn’t the problem here. Loss of the knowledge embedded in the system is.

The distinction matters because the correct responses to each are almost diametrically opposed. Legacy code should be decommissioned or deliberately replaced and on a plan. Heritage code should be understood, protected and modernized carefully — in place, incrementally and without severing the business logic it carries.

What Heritage Looks Like in an Insurance Estate

For carriers, heritage systems are rarely hard to find once you go looking equipped with the right question. They often include rating engines that price risk using decades of actuarial refinement; underwriting rules that encode judgment calls made by underwriters who have since retired; and claims adjudication logic that reflects years of edge cases, exceptions and regulatory interpretation — logic that was never fully written down anywhere except in the code itself.

None of this is technical debt in the conventional sense. It’s closer to institutional memory that happens to be stored in COBOL rather than in a person’s head — which is itself the risk, given how much of that memory is concentrated in a shrinking, aging workforce.

A policy administration system that’s existed for 30 years may contain thousands of small refinements made in response to state regulation, product changes, claims experience and competitive pressure. Individually, many of those changes appear inconsequential. Collectively, they represent a body of operational knowledge that would be difficult to recreate from documentation alone. This is often where carriers discover that what appears to be technical debt is actually accumulated business expertise.

In many carriers, the greater risk is no longer only technical debt, but knowledge debt. The organization depends on business rules embedded within systems that few people fully understand and that may never have been comprehensively documented. Modernization efforts that remove the technology without first recovering the knowledge can increase enterprise risk rather than reduce it.

A Simple Heritage Test

The legacy versus heritage distinction becomes useful only when executives can apply it consistently. Before placing an application on a retirement, replacement or modernization path, carriers should ask four questions:

• Differentiation: Does this application encode business processes that materially distinguish us from competitors?
• Knowledge concentration: Would the retirement of key SMEs leave portions of the logic unexplained?
• Operational dependency: Would business operations become materially riskier if this system disappeared tomorrow?
• Replacement confidence: Could we accurately reproduce the application’s behavior from existing documentation alone?

Systems answering “yes” to most of these questions should be treated as heritage assets until proven otherwise. That doesn’t mean they should remain untouched. It means the modernization path must begin with discovery, validation and preservation of the business logic before the technology path is chosen.

The Cost of Getting the Distinction Wrong

Misclassifying a system in either direction is expensive, but the failure modes are different:

• Treating heritage as legacy leads carriers to migrate or rebuild systems without fully capturing the business logic they carry. The result is rating errors, claims mishandling or compliance gaps that surface only after the original system is gone and there’s nothing left to check the new one against.
• Treating legacy as heritage leads carriers to over-invest in preserving code that no longer reflects the business, out of caution or a mistaken belief that anything old on the mainframe must be load-bearing. The result is wasted modernization budget and continued exposure to a shrinking talent pool for systems that add little value.

The Gartner report states that “poor decision making regarding migration is not merely a budgetary overage; it is a threat to business and operational continuity. Falling for “seemingly magical solution” migration promises while ignoring a platform-smart approach leads to massive technical debt and critical enterprise risk.” I agree and would add that the same logic applies one layer down, at the level of individual applications: an estate-wide label like “technical debt” applied without workload-level discrimination recreates the very risk it claims to solve.

A Different Playbook For Heritage Systems

Heritage systems don’t need to be rescued from modernization — they need a modernization approach suited to what they are. Wholesale replacement asks a heritage system to prove, all at once, that it’s been perfectly understood. That’s rarely achievable or necessary. A more defensible playbook favors:

• API enablement: Exposing heritage business logic through modern interfaces so it can participate in a hybrid architecture without being rewritten.
• Incremental refactoring: Improving structure, readability and maintainability of the existing code in small, verifiable steps, rather than a single high-risk rewrite.
• Improved observability: Instrumenting heritage systems so that behavior, dependencies and edge cases become visible over time — building the documentation the system never had, rather than assuming a big-bang conversion will capture it in one pass.

The Gartner report notes “while generative AI is currently transforming the “discovery” phase — aiding teams in mapping extensive technical debt — and improving operational support through capabilities such as specialized CICS and JES agents for an aging workforce, it still has significant limitations when it comes to the automated conversion and migration of legacy code.“ This is precisely where AI belongs in a heritage strategy: as a tool for understanding and instrumenting these systems, not as a shortcut past that understanding.

Generative AI can help surface hidden relationships in large code bases, extract candidate business rules, map dependencies, support impact analysis, generate documentation and accelerate knowledge transfer from experienced practitioners. These capabilities don’t eliminate the need for human validation, but they significantly improve an organization’s ability to understand heritage systems before change occurs.

Where This Leaves “Technical Debt”

Technical debt is a real and useful concept for the applications it actually describes. The mistake is applying it as a blanket label across an entire mainframe estate, where it obscures the difference between code that should be retired and code that should be protected.

Insurance executives serious about workload intelligence need to ask, application by application: is this legacy, or is this heritage? The answer determines everything that follows, from retirement to careful, incremental modernization. The most valuable systems in many insurance enterprises aren’t necessarily the newest. They’re the systems that embody decades of accumulated business knowledge. Modernization succeeds when organizations distinguish between technology that’s outlived its purpose and technology that’s become the repository of institutional expertise. One is technical debt. The other is a strategic asset.

This is the second article in a multi-part series exploring how insurance technology leaders should think about their mainframe strategy in the age of generative AI. The first article argued that insurers are asking the wrong questions around the “mainframe exit” conversation.  

Frequently Asked Questions

What’s the difference between a legacy application and a heritage application?

A legacy application no longer aligns with business needs and may be a candidate for retirement or replacement. A heritage application may be just as old, but it contains business rules, operational processes and institutional knowledge that remain critical to the organization’s success.

Why is it risky to classify all legacy systems as technical debt?

Applying a blanket technical debt label can lead organizations to replace or migrate systems without fully understanding the business logic they contain. This can introduce operational, regulatory and customer-impact risks that may not emerge until after modernization is complete.

How can insurance carriers identify heritage applications?

Leaders should evaluate whether an application contains differentiated business capabilities, concentrates critical knowledge, supports essential operations or would be difficult to accurately reproduce from existing documentation alone. Systems that meet these criteria often warrant a more deliberate modernization approach.

What’s the best modernization strategy for heritage systems?

Rather than pursuing wholesale replacement, many organizations benefit from approaches such as API enablement, incremental refactoring, improved observability and AI-assisted discovery. These methods help preserve valuable business logic while improving flexibility, maintainability and integration with modern platforms.

Gartner, Too Big to Fail: Why Mainframe Exit Projects Are Likely to Fail in the Age of Generative AI, By Dennis Smith, Alessandro Galimberti, Tobi Bet, 8 April 2026. GARTNER is a trademark of Gartner, Inc. and/or its affiliates.