Every large enterprise has them: core systems built over decades, running quietly in the background. The people who built them have retired or moved on. There is no written specification, and often no automated tests.
Leaving them alone was a reasonable call for years. The system works, it makes money, and a rebuild would not have earned more. In most estates that call was made by default rather than by decision. Now, however, the deciding factors have changed.
Why this changed in 2026
This year, AI models reached a new level of capability: they can now find software vulnerabilities and chain them together. The risk was serious enough that early access was restricted, and the Chair of the Federal Reserve and the US Treasury Secretary convened the CEOs of major banks to discuss it. Within months, models with comparable capability became generally available from more than one major AI lab, with cyber safeguards built in.
The landscape has changed. Understanding legacy code used to take months of painstaking work, which made modernization slow and expensive. This new generation of models changes that. They can read decades-old code, map how it works and surface its weaknesses in a fraction of the time. The same capability does raise the stakes on security, because code that sits outside modern security tooling and is hard to patch becomes easier to exploit. But it also gives enterprises the best opportunity they’ve had in years to finally modernize those systems, and with the right approach, the benefits far outweigh the risks.
This changing landscape affects enterprises across every sector, from energy and healthcare to retail and legal. But regulators have pressured financial services institutions first because attackers have the most to gain from their systems.
Building around legacy code is no longer a working strategy, and the security risks will not get smaller. But security is not the only reason to act. Moving faster is already a priority for most businesses, and legacy code is often what holds them back. Modernization addresses the exposure while removing that bottleneck, allowing teams to respond faster to customers, regulators, and new opportunities.
Security forces the issue, and two older problems come with it
While regulators were most concerned with security risks associated with these new models, enterprises can also address compliance and talent problems while modernizing code.
- Compliance. Many of these systems predate GDPR. They cannot show where a customer’s data goes, and they cannot reliably delete a record when a customer asks. Audit and lineage obligations follow the data, and this applies to old systems as much as new ones.
- Talent. The people problem is growing too. People with COBOL, RPG, and early .NET skills are hard to hire and harder to keep. The people who remember how the system works are leaving, so maintenance costs more as the skills get scarcer.
What used to stop modernization has mostly gone
Before, there were significant barriers to modernizing code, primarily the time and resources it would take to properly assess and rework the estate. The senior engineers who know the estate best were busy keeping it running. Now, agents offer a fast, pragmatic solution.
Understanding the estate formerly depended on the few people who still knew the code. Now we run an agentic audit, mapping the whole estate and its dependencies, what it does, and what is of no use anymore. For a software provider, we used agents to map 30 years of history in just two and a half hours. This created a complete baseline to track all future iterations.
The agentic audit also reduces the scope and volume of work. It reveals redundancies that do not need to move at all. At an electricity distributor, our agents analyzed 6,000 reports in 72 hours and found about 60% redundant. Those reports were retired, reducing the scope of the migration and future support. Agents also take on the volume, so experts can focus solely on decisions. At an energy company, we delivered six months of planned work across 155 applications in a week. We consolidated applications onto a customer’s serverless platform, enabling monitoring and observability to ensure accuracy and uptime.
The hard part is proving the new code is right
Converting old code is the easier half of the job. The harder half is knowing that the new system does what the business intended. The code alone cannot tell you that. It records what someone wrote, not what they meant. A workaround added years ago can be indistinguishable from logic the business still depends on, and so can a module that no longer runs. Tests generated from the old system will confirm that the new one behaves the same way, bugs included, which shows consistency but not correctness.
That is why your domain experts sit at the center of the process. They review what the system does and rule on it, deciding that one behavior is intended and another is a defect nobody should carry forward. They make those calls in workshops, so their time goes to judgment rather than code. Each ruling becomes a check that every converted piece must pass, and the work moves in a loop: read the code, confirm with the experts, convert it, test it, correct the rule where the test disagrees, and go around again.
Sometimes the analysis finds no clean place to cut. When that happens we say so and stop, because we would rather tell you early than sell you a rewrite that cannot be proven.
Where Anthropic fits, and what we add
Anthropic publishes official plugins for Claude Code that give teams a starting point for modernization work. Its Code Modernization plugin takes a codebase through assessment, security hardening, planning, conversion, and verification, with a checkpoint where business rules get reviewed. As an Anthropic Preferred Partner, Indicium AI starts from that plugin and adapts it to each client’s estate, adding our own knowledge base and our experience in regulated environments.
We also modernize the practice, not just the code. We bring our agentic software development lifecycle (SDLC) to the way your team runs the program: engineers direct, agents build, and every change is reviewed before it ships. Your team learns the practice during the modernization and keeps it afterward. The modified plugin changes the code; the agentic lifecycle changes how the team works. If the practice stays the same, the habits that produced the legacy estate will produce the next one.
What you get is current code and a team that ships faster on everything else. Applications that still grow stay with a product team that owns them with Claude Code.
The obvious question is: why not just use the plugin? On its own, it is the starting tooling. A program also needs the plugin customized to your estate, your experts engaged, a team whose practice changes with the code, and cutover in small, reversible steps. That is the work we do inside client teams.
Not everything needs a rewrite
Analysis decides the treatment for each application: retire it, rebuild it, move it to a new platform, or keep it with a documented reason. Code that must keep running but rarely changes can move to agent-run maintenance, where a software factory monitors it, patches it, and gates every change, with people handling exceptions. That ties back to security: code you keep still gets patched, and keeping it costs less.
Where to start
- Assess before you choose. Get the estate assessed before picking an approach. Our indicative route completes the assessment by weeks 4 to 6.
- Name your domain experts early. Protect their time. Their rulings are the critical input to the whole program.
- Rank by value and exposure. Start where both are high.
- Start with real complexity. An easy first piece teaches you very little about the rest.
- Decide each application’s future. Keep growing it, run it cheaply, or retire it.
If you want to know where your own estate stands, get in touch.
