ProAg, a crop insurance provider in the United States, runs most of its current quoting, claims, and policy operations on a Windows-only stack. The applications carry more than a decade of specialized business logic, and ProAg has decided to re-platform them onto the cloud using the classic strangler pattern. In one case, modernizing a single process to the cloud took over six months and tied-up a small team of resources in the process.
Intellias took on one of the more complex processes in the estate and produced a modernized version in five weeks, validated against the legacy system end-to-end. The migrated build ran in parallel with the legacy process, with outputs compared at every stage, not just at the boundaries — establishing that the approach works on production-complexity code, not that the output is itself production-ready without further hardening. This post covers the challenge ProAg was facing, the approach we proposed, how we did the work, and what the numbers look like on the other side.
The challenge: A regulated estate that resists modernization
Crop insurance in the US is heavily regulated. Every line of code that touches policy pricing, premium calculation, or claims must satisfy the Risk Management Agency. That, plus a decade of incremental development, makes the estate hard to move:
- Hundreds of business processes spread across multiple Windows services, data stores and other complex dependencies.
- A very large codebase.
- Hard dependencies on Windows-specific libraries that block any move to .NET Core 10 or containerization.
- Heavy reliance on manual testing for regressions.
- Out-of-date documentation for code which has evolved over the years.
Standing still is not free either. The legacy .NET Framework stack has a defined end-of-support date – time spent on maintenance is time not spent on new products.
The cost of doing it the traditional way is high. Multiplied across the estate, ProAg’s own baseline implies a multi-year program at six months per process.
The proposal: Agentic AI inside ProAg’s regulated environment
We proposed a four-week project to migrate one of the most complex processes onto the new target stack using agentic development, with two conditions:
- Pick the right process, not the easy process. The point of the project was to answer the question can this approach handle the work we actually have to do? — so we deliberately took on a high-complexity, high-business-value process rather than a benign one.
- Validate against the core system, end to end. Generating code is the easy part; matching the outputs of the production system is what we had to prove. The validation framework was scoped as a deliverable in its own right.
The target architecture was set jointly with ProAg engineering: follow the existing migration strategy to move from on-premises .NET 4.8 Windows to modern .NET Core, containerized to run on AWS EKS.
How we did it
1. Map the estate before scoping the work
Before touching the process itself, we ran two AI-driven documentation passes: a broad sweep across the legacy estate for surrounding context, then a deeper pass over the in-scope codebase to capture how classes, stored procedures, data stores, and feature flags interact. We also pulled in patterns from related repositories and previously migrated processes that ProAg’s engineers had already established.
By the end of week one, the team had a map of how the in-scope process connected to the rest of the estate. Both the engineers and the agents worked against that documentation for the rest of the project.
2. Generate the migration plan
From the documented codebase, we generated a migration plan covering architectural decisions, library replacements, and the test harness. A few forks the plan had to call out up front:
- Some legacy components could not be ported as-is. A subset was swapped for modern equivalents already in use elsewhere in the customer’s estate; others had to be rewritten.
- The orchestration model also needed to be updated to align with the modern target architecture.
3. Migrate stage-by-stage with hard validation gates
The process decomposes into four stages: data retrieval, filtering, processing (the calculation core), and report preparation. We migrated stage by stage. At each boundary, the legacy and migrated runs were compared by a custom validation framework that confirmed outputs matched before moving on.
Writing the code was never really the problem; proving it matched the legacy system, line for line, was. That’s why we built the validation harness alongside the migration rather than after it.
4. End-to-end validation against the legacy system
With every stage gate green, we ran the full end-to-end validation: the migrated process and the legacy process executed against the same production-representative inputs, with outputs compared field-by-field by the validation harness. Every output field matched, and the harness produced a per-field diff report that ProAg’s team kept as the artefact of record.
The outcome
100% data match. Every test we ran produced identical output to the legacy system. Customer feedback from ProAg’s engineering leadership:
Intellias did a great job proving to us that we can build software differently using AI. In 1/5th of the time it took one of our internal teams without AI to do something similar, Intellias gained quick understanding of the code, converted from .Net Framework to .Net8, converted PDF generation of a complicated document to a new platform, and all within our complex DEV and QA environments. They showed that we can’t just ‘use AI’, but that we need to ‘use AI intelligently’.
A reusable harness for the rest of the estate. The validation framework, the codebase documentation pattern, and the agent templates are not single-use; they carry over to the remaining processes, and each one should be quicker than the last.
The numbers
Headline efficiency: Roughly 3–5× faster and cheaper than ProAg’s internal baseline.
Beyond the per-process number, the modernized process resolves performance and stability issues that the legacy version still carries. Senior engineering capacity that would have been locked into legacy migration for years is freed for new products, new customer experiences, and the next generation of crop insurance.
The migrated process also resolves performance and stability issues the legacy version still carries. Engineering capacity that would otherwise have been spent on migration for years is freed for the work the business wants to fund.
What this means for the rest of the estate
The project answered a narrower question than ProAg originally asked. The approach — AI-driven codebase documentation, generated migration plans, validation-first execution, hard exit gates — held up on one of the most complex processes in the estate, inside a regulated environment, and produced output that matched the original core system.
For an estate this size, that is the difference between a multi-year traditional migration and a phased, AI-led program that gets faster as it goes — and between buying a vendor-delivered IT project and running an engineering program that uplifts the in-house team along the way.
Modernization as capability transfer, not outsourced labor, is what matters most for an FSI organization looking at its own estate. Technology is no longer the gating factor. The gating factor is whether the customer comes out of the engagement with engineers fluent in the new stack.
About the engagement
This work was delivered by Intellias’s FSI AI practice. Intellias has run the same agentic-AI-led modernization pattern on a comparable engagement with other customers.
If you are running a multi-year legacy modernization program and want to see what this approach would look like on your estate, get in touch.