Vetting Agentic Application Modernization: What Insurance IT Leaders Need to Know Before They Commit

Agentic application modernization, the use of coordinated AI agents to analyze and upgrade software, can rewrite legacy insurance apps by “asking” the agents to mine requirements, plus design, build, and test code—all while human architects set priorities and validate the work. Because agents handle repeatable engineering at scale while people own judgement and accountability, agentic modernization can compress 12- to 16-week rewrites into roughly two weeks, potentially cutting costs by 30 to 50 percent.

Who This Is For:

CIOs, CDOs, VPs of application development, and heads of enterprise architecture at P&C carriers who need help evaluating agentic application modernization so they can ask the right questions, determine if it’s right for their organizations, identify and approach, and manage risk

In Brief:

• Agentic modernization runs as a supervised pipeline of specialized agents. The agents handle requirements mining, design, coding, and testing, while human architects own prioritization, validation, and the calls that carry real risk.
• Agents take on repeatable work while people own judgement and accountability. Exhaustive, parallel engineering tasks that once priced manual rewrites out of the budget become fast and affordable, making a two-week timeline realistic.
• Where you start matters more than speed. A four-factor prioritization screen (maintenance cost, integration risk, knowledge concentration, and vendor support risk) tells you which app in your backlog should take the first rewrite.
• When evaluating agentic application modernization projects, look for software that is costly to operate, integrated deeply into your systems, understood by few employees, and lacking vendor support.

As a P&C IT leader, you’ve probably stopped arguing about whether the legacy technology backlog is a problem. Applications built on aging IBM, Microsoft, and Java technologies—along with legacy collaboration platforms and database-centric architectures—quietly consume a large share of the IT budget and sit between your team and the AI roadmap your organization has already funded.

But now, a harder question is on your desk: Should you use AI agents to clear your legacy technology backlog?

That decision doesn’t require writing the code or designing the pipeline, but it does require a working model to separate a sound approach from a risky one. Currently, coordinated, multi-agent systems that handle complex engineering tasks are replacing single-prompt tools for app rewrites, making a full rewrite something a small, supervised team can run.

The questions you need to answer are narrower: Where does a human stay accountable? How do we optimize speed and cost? Which application should go first? And which AI model is appropriate for the work at hand?

Our first post in this series established why the legacy technology backlog is a problem worth solving. This post is the evaluation guide. It provides enough information about how agentic modernization works to vet it, determines where the human control points sit, and explains the economics. It then presents a four-factor screen for choosing the first project.

But what does “agentic application modernization” mean, and how does it work?

What Is Agentic Application Modernization?

Agentic application modernization uses multiple specialized AI agents, each handling a defined engineering task, to rewrite a legacy application under human supervision. However, it’s more than a single chatbot writing code. It runs as a pipeline of agents that document, design, build, review, and test, all with experienced architects directing the sequence and approving the output.

The distinction matters, because the early wave of AI coding tools worked one prompt at a time. A developer asked for a function and got a function, which was useful but did not move a whole application.

Today’s shift is from autocomplete to orchestration. In an agentic rewrite, people move into supervisory roles and oversee squads of AI agents that document the legacy application, write new code, review each other’s code, and integrate features that other agents test before delivery.

Think of it less like hiring one very fast developer and more like running a small, tireless engineering shop where you are the lead architect. The agents never get bored reading 200,000 lines of undocumented legacy code, while you spend your time on the decisions that require a human.

Agentic modernization is a supervised pipeline of task-specific agents, with humans directing the sequence and approving the output at each stage.

Once you see it as a pipeline, the obvious question is what each stage does—that’s where the real work lives.

How the End-to-End Pipeline Works, Stage by Stage

Agents need three pieces of information before they start: the business requirements in plain language, the acceptance criteria that define what “done” means, and the design and coding standards to build against.

What comes back is working software that meets those standards, plus the tests and traceability that prove it. Rather than managing every step in between, you manage the intent going in and the evidence coming out.

Underneath that framework, the work still moves through five phases, and a person signs off at the end of each before the next begins. Those are the same five phases your traditional software development lifecycle (SDLC) runs through, and they produce many of the same deliverables leadership already expects. Here’s what happens at each step and where you stay in control:

From legacy code to modernized system: a four-stage agentic pipeline that mines requirements, redesigns architecture, builds with AI-driven code generation and review, and delivers test coverage beyond manual scale.

1. Establish Ground Truth

A person confirms that what the agents reconstructed matches what the system actually does before anything gets built on top of it. Agents read the existing code, or the documentation and transcripts you have, and turn it into a knowledge graph or call graph your team can query instead of relying on decades of tribal memory.

2. Map the Impact

Before anyone writes a line of new code, a person reviews the impact map and the generated test set against your standards. Once ground truth exists, agents assess what a given change touches. Then, they produce the map, plus an initial test set for the architect to approve.

3. Plan and Build

Every line produced by coding agents is reviewed against your coding standards before it moves forward, much the same way a senior engineer reviews a junior developer’s pull request. Coding agents break the approved design into waves and build against it, while a second set of agents reviews that code continuously rather than at the end of a sprint.

4. Test and Triage

Humans confirm fixes and still run the exploratory, judgment-driven testing that scripted and generated coverage can’t replace. Testing agents run unit, system, and integration tests and handle the first pass of defect triage, which is how agentic rewrites reach automated coverage of 80 or 90 percent.

5. Deploy

Whether to release remains a human decision. Agents assemble the release package and deployment record, but nothing reaches production without a human signing off on it.

Each phase “hands” a validated artifact to the next, and nothing advances without one of those five sign-offs. What’s different from the SDLC you already run is the execution model underneath it, as well as where your judgment must sit.

This process also changes what paperwork is worth producing. A test strategy document written to satisfy a review gate does little for a team that generates and runs its own tests. Retain the artifacts a person actually reviews and remove the rest.

The pipeline explains the activity but does not explain the economics. For that, let’s look at what work the agents absorb.

Why Multi-Agent Execution Changes the Cost and Speed Equation

Agentic modernization compresses timelines and cost because AI agents take on the high-volume engineering that consumes most of the hours in a traditional rewrite: reading the old code, generating boilerplate, and writing tests. People keep the parts that need a human, like setting direction, weighing trade-offs, and approving the output. In our experience, a 12- to 16-week rewrite can be delivered in roughly two weeks at up to half the cost.

Those savings come from changing what people spend their time on rather than cutting labor rates. Test generation is a clear example: A study published on the curated research-sharing platform arXiv found that agent-based generation can run continuously and produce broad coverage faster than handwritten test suites, the kind of repetitive task that drains a manual project.

For a leader, the claim worth pressure-testing is this division of labor. Agents do not get bored, so the tedious reading (and the 10-thousandth test case) gets completed. The architects spend their time on the rating and underwriting rules that carry regulatory weight, where a wrong call is expensive to unwind.

Model selection is part of that same economics. Reverse-engineering years of undocumented, nonstandard legacy code calls for a model with deep reasoning capacity, patient enough to trace tangled logic across thousands of files without guessing. Generating new code against an already approved design is a more mechanical job—one that a lighter, faster model often performs more cleanly. A heavier reasoning model can overthink a well-defined build step and produce a more convoluted result than a simpler one could. When you evaluate a partner, ask which models run what stages and why. Matching the model to the task is as much a part of the savings as the agents themselves.

The economics hold up when agents carry the volume, people keep the decisions, and the model fits the work.

Speed and savings only matter if they’re aimed at the right system to modernize first; choosing that system is where these efforts often go wrong.

How to Decide Which App to Modernize First

We recommend a four-factor screen to rank your backlog, because the right first rewrite is rarely the oldest app or the loudest problem. Instead, it’s the rewrite where cost, risk, fragile knowledge, and AI dependency converge. When evaluating agentic application modernization proposals, score each candidate application against the following:

1. Maintenance cost versus value delivered: What does it cost to keep this app running each year, and how much business value does it return? High cost plus low strategic value is a strong rewrite signal.
2. Integration risk: How many systems depend on this app, and how brittle are those connections? Apps that sit on critical integration paths carry outsized operational risk the longer they run.
3. Knowledge concentration: How many people still understand this system, and how close are they to retirement? When institutional knowledge sits with one or two people, every year of delay raises the risk of significant and hard-to-recover knowledge loss.
4. Lack of vendor support: Is the vendor sunsetting the platform or already treating it as end-of-life? Technology that a vendor no longer supports carries security gaps and prevents other upgrades. Both risks compound the longer you wait.

An app that scores high on all four factors—expensive to run, deeply integrated, understood by almost no one, and no longer supported by vendors—is the strongest candidate for your first rewrite.

Translating that modernization effort into a figure leadership will approve is a separate exercise—one we cover in the next post of this series.

Frequently Asked Questions