Most legacy modernization programs don’t fail in delivery. They fail to start.
AI can now write code in minutes, yet a change to a core system still takes a year. For a long time, ‘too risky’ was enough to end the conversation. It no longer is. And in most steering committees, ‘too risky’ is shorthand for four separate concerns:
- “We don’t know where to start.”
- “We can’t risk breaking the business.”
- “We’ll be back here in five years.”
- “Testing will eat the timeline.”
Each objection is reasonable. Each one also has an answer.
1.”We don’t know where to start”
Most enterprises don’t have one legacy application. They have hundreds, built over decades, inherited through mergers, and written by teams that have since moved on. Ask which one to modernize first and you get as many answers as there are application owners.
Without a shared yardstick, programs either stall in analysis or start with whichever system has the loudest sponsor. When that first project turns out to be low value, confidence in the whole program goes with it.
The fix is to start with the portfolio, not the project. We begin with an assessment of the full estate: automated discovery of code, dependencies, runtimes, licenses and usage, plus short interviews with the business owners who rely on each system. Every application is then scored on five dimensions:
- Business value. How critical it is, how many people and processes depend on it, and how often the business asks for change.
- Security and compliance risk. Open vulnerabilities, unsupported runtimes and audit exposure.
- Hard deadlines. End-of-license, end-of-support and contract renewal dates, which often set the real timetable.
- Cost. Run cost, license cost and the cost of making each change.
- People risk. How hard it is to hire people who know the technology, and how much depends on a few individuals.
Plotting value against risk shows at a glance where each application belongs.
Each application then gets a disposition:
| Disposition | Fits when | Typical trigger |
| Retire | Little use, or duplicated elsewhere | Overlap after a merger, an upcoming license renewal |
| Retain | Stable, low risk, rarely changed | Nothing urgent; review next cycle |
| Rehost | Sound application on the wrong infrastructure | Data-center exit, hardware end of life |
| Replatform | Small changes unlock a managed service | Database or middleware end of support |
| Rearchitect / rewrite | Core to the business and blocking change | Security exposure, obsolete stack, scarce skills |
The result is a sequenced roadmap, not a wish list. Applications that share data or integrations move together. The first wave is chosen to retire visible risk quickly and free up run cost, so early savings help fund later waves. And the roadmap is revisited after each wave rather than set once and forgotten.
2. “We can’t risk breaking the business”
This fear is justified. In a study posted in August 2026, a coding agent migrated twelve features of an enterprise system that had run for more than twenty years. Behavior matched the original 92% of the time for simple features but only 47% for complex ones. In total, 100 of 331 business rules and database operations were not migrated correctly. [1] The agent built what it was pointed at and missed what sat beside it, such as batch imports, reports and notifications.
The real risk is changing a system you have never fully described. So we capture behavior before any code changes, in seven behavior-driven (BDD) stages:
- Discovery. Inventory code, data and integrations.
- Intent extraction. Catalog every business rule, each with an ID.
- Capability mapping. Group rules into capabilities and migration waves.
- Behavior lock-in. Write today’s behavior as executable Given/When/Then tests.
- Modernization approach. Design the target and choose the path.
- Co-create. AI agents generate code against the locked tests, with expert review.
- Parallel run. Run old and new side by side and cut over on evidence.
Stage 5 chooses one of three destinations:
| Upgrade | Modernize | Reinvent | |
| In short | Same road, made safe | New stack, same experience | New stack, new business |
| Choose it when | You’re on a modern stack but behind on versions | The stack is obsolete but the process works | The process itself must change |
| Disruption | None | Low | High by design, but manageable |
| What you get | Risk removed, nothing else moves | A supportable platform, same business | A business that works differently, with agentic AI built in |
Even Reinvent starts from stages 1 to 4. You can’t safely reimagine what you haven’t understood.
3. “We’ll be back here in five years”
This is the objection CFOs raise, and it comes from experience. Many modernizations end with new code and the same knowledge gap. The delivery team leaves, documentation is written once and drifts, and new business rules pile up in code nobody has described. Within a few years, every change takes months again.
Legacy, it turns out, is less about the age of the code than about how little anyone knows about it. Fix the code without fixing the knowledge and you have only reset the clock.
So we treat modernization as the start of a new way of building, not a one-time project. Delivery runs through an Agentic Development Lifecycle (ADLC) in four stages, with a human approval at each gate:
- Ideate. Agents turn business intent into requirements, epics and user stories with testable acceptance criteria.
- Architect. Agents produce the target architecture and a technical specification for each piece of work.
- Generate. Agents build the code against the approved specifications, in parallel where the work allows.
- Certify. Agents test the result against the acceptance criteria, and people sign off before release.
Along the way, the ADLC builds a context lake: a living, searchable record of how your application works and why. It holds every business rule with a permanent ID, the specifications and architecture decisions with who approved them, the executable behavior tests, and the links from each rule to the code that implements it and the test that proves it. Because agents update it as part of every change, it stays current instead of drifting.
That changes what an enhancement looks like. Say the business asks for a new pricing rule. An agent first queries the context lake: which rules, screens and integrations does this touch, and which tests cover them? It drafts the story and specification, people approve, the code and tests are generated, and the test harness proves nothing else broke. Work that used to begin with weeks of investigation starts from documented intent, and the next enhancement takes a fraction of the time.
The context lake pays off beyond delivery, too. New engineers learn the system from the record rather than from whoever is left. Auditors can trace a rule to its code and its test. And you own all of it, the code, the specifications, the tests and the knowledge, so your own team can keep building after the program ends.
4. “Testing will eat the timeline”
AI made code cheap. It didn’t make proof cheap. On most modernization programs, testing is where the schedule slips, for three reasons:
- No automated tests. Legacy systems rarely have them, so every release means another manual regression cycle.
- No definition of correct. Expected behavior isn’t written down, so testers can’t say what “right” looks like.
- Late checks. Security and performance are tested just before go-live, when problems are most expensive to fix.
Writing code ten times faster fixes none of this. It just moves the queue to QA.
We close the gap with an agent-based test harness that runs from day one, not in a final phase:
- Functional. The behavior tests locked in stage 4 become automated tests. Agents run them on every build and keep them current as the code evolves.
- Test data. Agents generate realistic synthetic data that covers boundaries and edge cases, so production data doesn’t have to be copied into test environments.
- Security. Static analysis, dependency audits and vulnerability scans run on every build, so issues are fixed while they are small.
- Performance. Load and response-time tests are measured against the legacy system’s own numbers, so “as fast as before” is proven, not assumed.
- Independent evaluation. The agent that writes the code never grades its own work. Separate evaluator agents check it, and people resolve the differences automation can’t interpret.
At cutover, the harness produces an evidence pack: every test result, every difference between old and new, and every security finding with its resolution. The go/no-go decision is made on that evidence, and the same pack answers auditors later.
After go-live, the harness doesn’t leave with the delivery team. It becomes the regression suite for every future change, connected to the context lake, which is what lets the business move faster without adding risk.
In practice
A biopharma manufacturer of sterile injectable medicines needed a more secure foundation for an aging .NET application, without changing the behavior its users relied on. Using the seven-stage method, the team captured behavior first, then proved it with 243 automated tests and parallel runs alongside the legacy application.
The modernization took six weeks against an estimated eleven for a traditional approach, at 37% lower development cost and with no disruption at cutover.
How it fits together
The portfolio review decides what to change. The seven stages change it safely. Agentic delivery and the test harness prove it and leave behind a context lake that makes the next wave faster than the last.
How the four answers connect · 4 steps feeding one context lake
Before you answer the board, pick one shelved application and ask for proof on a thin slice: behavior captured, the new version running beside the old, every difference documented, and your own team able to own the result. If no one can show you that, the application isn’t too risky to change. You just haven’t been shown a safe way to try.
Sources
- Alves, Iago da Silva Rodrigues, Cristiano Politowski, and João Eduardo Montandon. “Legacy System Modernization with Coding Agents: A Case Study.” arXiv preprint, August 29, 2026. arxiv.org/abs/2608.28972