Modernization Is Not the Hard Part. Starting Is.
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