A policy administration system built in the 1990s doesn’t just hold data; it holds decisions. Which rate table applied to a renewal three years ago. How a mid-term endorsement should adjust a premium. What happens when a claim touches two overlapping coverages. None of that logic is necessarily written down anywhere except in the code itself, often scattered across programs, stored procedures, and batch jobs that were never designed to be read together. Change one component to fix an unrelated problem, and a downstream billing job or claims calculation can quietly start behaving differently.

This is the specific difficulty of insurance modernization: the risk isn’t really about old technology; it’s about undocumented business behavior sitting inside that technology. AI can help teams work through it by analyzing unfamiliar code, mapping dependencies, drafting documentation, generating candidate code, and supporting test creation. What AI cannot do on its own is guarantee that a modernized system behaves exactly like the one it replaces, or remove the need for engineers and business experts to validate that it does.

This article sets out how AI can realistically assist with legacy code refactoring, code translation, and insurance modernization more broadly, and where human validation, testing, and controlled release remain non-negotiable.

Key Takeaways

• AI can accelerate discovery, translation, and testing in legacy code refactoring, but it cannot prove business-rule equivalence.
• Recover and validate business behavior before generating replacement code.
• Modernize bounded components rather than treating the monolith as one conversion job.
• Compare legacy and modern behavior before expanding scope, and classify every difference.
• Treat insurance modernization as architecture, data, and operations, not just language translation.

Why Are Legacy Insurance Systems Difficult to Modernize?

Legacy insurance systems, the starting point for any insurance modernization, have often evolved over decades to support changing products, business operations, and regulatory requirements. These challenges make migration a complex process:

1. Business Rules Are Embedded in the Code

Any legacy code refactoring effort in insurance has to contend with rules governing policy eligibility and coverage, premium calculations, endorsements and renewals, claims decisions and payment processing, billing schedules and adjustments, and state-, product-, or jurisdiction-specific requirements.

Much of this logic was written to satisfy a specific regulatory or business requirement at a point in time, and the reasoning behind it may never have been documented separately from the code. It is also rarely centralized. A premium calculation, for example, might touch a core program, a stored procedure, and a batch job that applies year-end adjustments, with no single place that describes the full picture.

2. Dependencies Extend Beyond Individual Applications

Policy administration, claims, billing, underwriting, document generation, reporting, and external services (rating engines, reinsurance systems, regulatory reporting feeds) are usually connected through years of point-to-point integrations. Changing how one component calculates or stores a value can affect a downstream system that was never part of the original migration plan, simply because it reads the same table or receives the same batch file.

3. Production Changes Carry Business Risk

Unlike a greenfield build, a legacy insurance system usually has active policies, open claims, and financial transactions running through it continuously. A migration has to account for in-flight work, such as a claim mid-adjudication or a renewal mid-cycle, not just a clean cutover between two static states.

4. Legacy Knowledge May Be Concentrated in a Small Number of People

Where documentation is thin, legacy code refactoring depends on understanding how the system actually behaves, which often lives with a small number of long-tenured engineers or business analysts. Their departure, retirement, or simple unavailability during a project can leave gaps that only the code itself, and careful analysis of it, can fill.

What Is AI in Legacy Code Refactoring?

AI in legacy code refactoring refers to using AI assistants or agentic tools to help with understanding, restructuring, testing, documenting, or translating existing software, with engineers validating the resulting changes at each stage.

It’s worth separating three activities that get used interchangeably but aren’t the same thing:

These can overlap in a single project, but translating a program’s syntax into a new language does not by itself modernize its architecture, and refactoring a component’s internal structure doesn’t necessarily change what language it’s written in. Code translation is what most people mean when they talk about “using AI to move off COBOL,” but it is one part of a larger insurance modernization effort, not a stand-in for the whole thing.

How Can AI Support Insurance Legacy Modernization?

AI can take on several distinct roles within a modernization project. These are possible responsibilities within an engineered workflow, not a claim that every project needs a separate tool or agent for each one. Current enterprise tooling points the same way: in a modernization workflow AWS and OpenAI published, AWS Transform for mainframe first reverse-engineers COBOL, PL/I, and JCL systems into business functions, business rules with source-line traceability, and technology-neutral requirements. Only then does a coding agent handle forward engineering. Recovering and validating behavior before generating the replacement is the same principle this article recommends.

1. Legacy Code Analysis

In legacy code refactoring, AI can help engineers work through large, unfamiliar codebases faster: identifying program structures, summarizing what an unfamiliar module appears to do, and flagging candidate areas for modernization. This doesn’t replace reading the code; it narrows down where engineers should look first.

2. Dependency Mapping

AI-assisted analysis can help surface calls between programs, shared data structures, database dependencies, batch processes, and external interfaces. But AI analysis should complement, not replace, static code analysis, call graphs, database and schema analysis, runtime telemetry, batch schedules, and integration inventories.

A language model reading a repository cannot reliably discover dynamically resolved calls, runtime configuration, scheduler behavior, shared files and tables, or external consumers that never appear in the source.

Treat AI-generated dependency maps as a starting hypothesis, then verify them against the actual source code, runtime evidence (what the system does when it actually runs), and the knowledge of people who have worked with the system.

3. Business-Rule Discovery

AI can help extract candidate business rules from code and documentation, such as an eligibility check buried in a conditional statement, a premium calculation spread across several subroutines, or a claims-processing condition tied to a specific product code. Before any of these candidate rules become specifications for a migration, business owners and subject-matter experts need to confirm they’re accurate and still current.

One distinction matters here: code behavior is not necessarily current business intent. Legacy code sometimes encodes rules that were later superseded but never removed. Without that check, teams can make the opposite modernization mistake and faithfully recreate every legacy behavior simply because the old code did it.

4. Code Generation and Translation

Once specifications are validated, AI can assist with generating or translating code during legacy code refactoring, using the source implementation, approved specifications, and existing tests as context. Generated code in legacy code refactoring still needs the same review any new code would get: correctness, maintainability, security, performance, and compatibility with the target environment.

5. Test Generation and Documentation

AI can help draft test cases, explain unfamiliar logic in plain language, and produce documentation for components that previously had none. Generated tests can miss important edge cases, particularly ones tied to business rules the AI wasn’t given visibility into. They support the testing effort but can’t independently prove the migrated application behaves correctly.

How Does AI-Assisted Code Migration Work?

AI-assisted code migration, like any legacy code refactoring effort, works best as a controlled, staged workflow for moving a bounded component from its legacy implementation toward a modern target, not as a single conversion step.

1. 1. Analyze the existing application: Inventory the relevant programs, interfaces, databases, batch jobs, and dependencies. For an insurance application, this includes understanding how the selected component interacts with policy records, billing, claims, or other connected systems.
2. 2. Extract and validate business rules: Use AI-assisted analysis to identify candidate rules and document current behavior, then have engineers and insurance subject-matter experts verify the findings and resolve anything unclear or contradictory before proceeding.
3. 3. Select a bounded component: Choose something with a clear business purpose and manageable dependencies, not the entire monolith in one operation.
4. 4. Generate or translate the target implementation: Produce the target code using the source implementation, validated specifications, dependencies, and tests as context, then run it through code review, static analysis, security checks, and a compatibility assessment.
5. 5. Compare legacy and new behavior: Test both implementations against representative inputs and scenarios, comparing outputs, state changes, exceptions, calculations, and relevant side effects (see the next section on how to interpret differences).
6. 6. Integrate and release under controlled conditions: Introduce the new component through a planned integration and release process, with monitoring, approval gates, rollback planning, and data-consistency checks.

How Do You Prove Legacy Code Refactoring Preserved Behavior?

The practical technique for verifying legacy code refactoring has a name: characterization testing, often called golden-master testing. The team captures how the current system behaves for representative scenarios, runs the same inputs through the modernized component, compares outputs, state changes, and side effects, and investigates every difference.

Not every difference is a defect, though. During insurance modernization there may be intentionally corrected legacy bugs, deprecated rules, changed regulatory requirements, or deliberately changed performance and interaction behavior. Classify each difference as one of three types before treating it as a failure:

This also means being explicit about which behavior must stay equivalent and which behavior is approved for change. Premium calculations, claim payments, financial state, and regulatory outputs usually belong in the first group.

Obsolete workflows, inefficient processes, known legacy defects, and deprecated integrations may belong in the second. Agreeing on that line with business owners up front gives them a defined role in the migration contract.

Modernizing COBOL to .NET With AI: What Should Insurance Teams Consider?

“COBOL to .NET” does not describe one universally defined transformation. Two materially different COBOL to .NET options are often confused:

Decide which COBOL to .NET path your project means before scoping it. AI assistance applies to both, but the validation effort differs. Whichever path you choose, a few technical considerations tend to matter most in insurance contexts:

• Numeric precision:

Insurance calculations often depend on exact rounding rules, scale and precision, decimal handling, and currency handling. Equivalent-looking translations between COBOL numeric representations and C# types can behave differently, and a small difference can silently change a premium or payout by cents that compound over volume. Date and time semantics deserve the same scrutiny wherever they drive calculations.

• Data structures and semantics:

Legacy records and file layouts need careful mapping to the target data model; a COBOL copybook’s implicit structure doesn’t always translate cleanly into a relational schema or object model. A program can be functionally correct while still misreading historical data: sentinel values, packed decimals, historical status codes, nullable or default values, date formats, and character encoding all need explicit handling.

• Batch and transaction behavior:

Processing order, transaction boundaries, and error handling in the legacy system need to be understood and preserved wherever the business depends on them. Batch ordering alone can change results.

• Program dependencies:

Shared structures, program calls, and interfaces can affect how the migrated component behaves once separated from the system it was written inside.

• Runtime assumptions:

The original application may depend on platform-specific behavior with no direct equivalent in the target environment.

• Integration contracts:

Downstream systems may depend on existing message formats, field names, timing, or response behavior that the new implementation needs to preserve or explicitly renegotiate.

How to Refactor an Insurance Monolith Without Breaking Production

Legacy code refactoring in an insurance monolith requires teams to modernize the system while keeping essential business operations running. Policies, claims, billing, and financial transactions may continue to depend on the existing application throughout the migration. The challenge in legacy code refactoring is to introduce change without disrupting those operations, which makes the migration strategy and release approach as important as the code being refactored.

1. Consider an Incremental Modernization Pattern

The Strangler Fig pattern, named for a plant that gradually grows around and eventually replaces its host tree, is one approach worth considering when a system’s architecture and dependencies allow it. Rather than attempting to replace a monolith all at once, teams route selected functionality to a new implementation while the legacy system continues to handle everything that hasn’t been migrated yet. Whether this fits depends on the system’s architecture, who owns the underlying data, integration constraints, and whether business capabilities can be separated cleanly enough to migrate independently. Martin Fowler’s discussion of the pattern is a useful reference, including his caution that old systems contain behavior that may no longer be wanted.

2. Establish a Behavioral Baseline

Before changing anything, document and test how the legacy system currently behaves. That includes representative business scenarios, boundary and exception cases, outputs and state changes, integration behavior, and relevant batch and transaction processing. Where the existing requirements are unclear or undocumented, runtime evidence, meaning observation of what the system actually does, combined with subject-matter review is often the only reliable way to reconstruct the intended behavior.

3. Validate Before Expanding the Migration

Appropriate checks before expanding scope typically include unit and integration testing, regression testing, data reconciliation, performance testing, security testing, and business acceptance testing. How much testing is enough should track the business risk and criticality of the component; a batch report generator warrants a different bar than a claims payment calculation.

4. Plan Coexistence, Monitoring, and Rollback

During the period when legacy and modernized components run side by side, teams need clear routing logic, data-consistency checks, monitoring, defined release approvals, fallback procedures, and unambiguous operational ownership of both systems. Release design and the constraints of the specific system determine what continuity is actually achievable. Promising zero downtime regardless of those constraints tends to set up a project for a difficult conversation later.

What Can Go Wrong With AI-Assisted Legacy Code Refactoring?

The table below outlines common risks in AI-assisted legacy code refactoring, explains their potential impact, and identifies controls teams can use to manage them:

AI assistance changes how some legacy code refactoring work gets done. It doesn’t change who’s accountable for the result.

How Should Insurers Measure the Results of AI-Assisted Insurance Modernization?

Success in legacy code refactoring is worth tracking across four dimensions, with acceptance thresholds defined before the work starts rather than decided afterwards:

There’s no universal percentage improvement to expect here; results depend heavily on the specific system, the scope of the migration, and how rigorously the baseline was established beforehand.

How Ariel Can Support Legacy Code Refactoring and Modernization

Assessing a legacy application, understanding its dependencies and embedded business logic, planning an incremental approach, and evaluating the architecture and integration changes involved map onto the kind of insurance modernization planning Ariel’s enterprise application modernization work addresses. The right starting point depends on the specific application, its role in the business, its technical constraints, and what the organization is actually trying to achieve.

Frequently Asked Questions

1. What is AI in legacy code refactoring?

It’s the use of AI assistants or agentic tools to help analyze, restructure, document, test, or translate legacy code, with engineers validating the resulting changes at each step rather than accepting AI output directly into production.

2. Can AI translate COBOL to .NET?

AI can assist meaningfully with code translation, and COBOL to .NET can mean either a rewrite into C# or recompiling existing COBOL to run on the .NET CLR. Either way, a successful migration depends on understanding the underlying business rules, data structures, dependencies, runtime behavior, and integration requirements, none of which are resolved by the translation step alone. Testing and engineering review remain necessary regardless of how the code was generated.

3. How can insurers preserve business logic during insurance modernization?

By documenting and validating existing rules with subject-matter experts, establishing a behavioral baseline before making changes, and systematically comparing legacy and target outputs across representative and boundary scenarios rather than assuming equivalence. Just as important, business owners should decide which legacy behaviors must be preserved and which are approved for change.

4. Can an insurance monolith be modernized incrementally?

Often, yes, and incremental legacy code refactoring is usually safer than a single cutover, where the architecture, data flows, and business capabilities can be separated cleanly enough to manage the transition safely. Suitability depends on the specific system rather than being a given for every monolith.

5. What should be tested before an AI-translated component reaches production?

Functional and regression tests, boundary and exception scenarios, integration behavior, data consistency, performance, security, and business acceptance testing, scaled to the criticality of what’s being migrated.

6. Does AI-assisted legacy code refactoring remove the need for developers?

No. AI can assist with parts of the analysis, generation, and testing work, but developers and architects remain responsible for understanding the system, reviewing code, validating behavior, managing integration, and making the production decisions that follow.