The cost curve moved
For twenty years the business case for replacing a core system died in the same place: the estimate. The work was measured in years, the budget in eight figures, and the risk in the sentence nobody wanted to say out loud, which is that the thing running the company today would have to keep running while you rebuilt it.
That arithmetic changed. McKinsey's QuantumBlack team, writing on AI for IT modernization, describes a transaction processing system at a large financial institution that would have cost well over $100 million to modernize three years ago and now costs less than half of that with generative AI in the loop. Tooling followed the same curve. Agentic assistants read COBOL, JCL, and VSAM definitions, infer intent, and emit Java or C# that compiles.
The conclusion a lot of boards are drawing from this is that modernization got solved. It got cheaper. Those are different statements, and the distance between them is where the next round of failed programs is going to come from.
What got cheaper, and what did not
Translation got cheaper. Comprehension got cheaper. Documentation of a codebase nobody has understood since 2011 got dramatically cheaper, and that is a genuine unlock.
What did not get cheaper is the part that actually consumes a modernization budget: establishing what the current system does, deciding which of those behaviors are requirements and which are accidents, and proving to a room of accountable people that the replacement produces the same answers.
The scale of what is waiting is not theoretical. In its 2025 review, GAO-25-107795, the Government Accountability Office identified eleven federal systems most in need of modernization. Three of the responsible agencies had documented plans covering all key practices. The other eight did not. In earlier reviews GAO put the age of the most critical of these systems between roughly 8 and 51 years, at about $337 million a year just to operate and maintain. Commercial estates look the same, they are simply less publicly audited.
Meanwhile the base rate on large change programs has not improved. Bain, drawing on a database of more than 24,000 initiatives, reports that about 12 percent of business transformations achieve their original ambition. Faster code generation does not move that number by itself. It moves the schedule, which means you arrive sooner at the moment where somebody has to sign off, holding the same unanswered question.
The old system is the only spec you have
Here is the situation on almost every legacy replacement worth doing. The requirements document, if it exists, describes the system somebody intended to build fifteen years ago. The system that actually runs has absorbed every patch, exception, and regulatory adjustment made since, and most of those were made under time pressure by people who have since retired.
So the behavior of record lives in exactly two places: the source code, and the heads of four or five people who know that the batch job has to run before the reconciliation or the totals come out wrong.
This is what makes AI translation deceptively attractive. It reads the first source beautifully. It cannot read the second one at all, and it cannot tell you which of the strange branches it faithfully carried across are load-bearing business rules and which are dead code from a product line discontinued in 2009. It will translate both with equal confidence. That confidence is the risk. A rewrite full of faithfully reproduced accidents is not a modernized platform, it is the same liability in a newer language, and now the people who understood the original quirks have nothing left to recognize.
Thoughtworks reached a version of this conclusion from the other direction. In their own write-up of legacy modernization in the age of AI, the model compressed comprehension and rewrite work from months into weeks, and the humans kept manual testing, business sign-off, and the judgment calls about where output diverged from production. Even the teams selling AI-first delivery put the verification burden back on people. That is the honest shape of the problem.
Capture the behavior before you translate it
The sequence that works inverts the intuitive one. Before any code is generated, the current system's behavior gets captured as something executable.
In practice that means characterization tests built from production reality rather than from documentation: real inputs the system has actually processed, paired with the outputs it actually produced, across a slice wide enough to cover the ordinary cases, the month-end and year-end cases, and the ugly ones support still talks about. You are not asserting the old behavior is correct. You are asserting it is the baseline, and that any deviation in the replacement has to be a deliberate decision somebody made on purpose rather than a surprise found in production.
This is also, usefully, the part where AI earns its money honestly. Generating a broad harness of characterization tests against an existing system, enumerating branches, and drafting the documentation of what each path appears to do is exactly the kind of high-volume, verifiable-by-execution work these models are good at. The tests either pass against the current system or they do not, so their quality gets checked by running them rather than by trusting them.
Once that harness exists, translation stops being an act of faith. The generated code has something to fail against.
Parallel run is the proof
The second discipline is refusing to treat cutover as an event. Run both systems against the same live inputs and compare outputs continuously, with the new one deciding nothing while it earns trust. Every difference is either a defect or an intentional improvement, and each one gets classified by a person before the list gets shorter.
What makes this affordable now is that the comparison is mostly automated and the investigation is mostly assisted. What makes it necessary is unchanged: it is the only mechanism that turns "the tests passed" into "we watched it agree with the system of record for six weeks, including month-end, and here is the log."
Then the cutover happens in slices. One product line, one region, one document type, one class of transaction. A rollback path stays live until the slice has been quiet for long enough to be boring. Programs get into trouble when the whole estate moves on a weekend because the schedule said so.
Traceability is what makes the argument winnable
Underneath both disciplines is a single property, and it is the same one we build toward on every AI system we ship: the platform can show its work.
On XCreos, the AI underwriting platform we designed and built for commercial real estate, the rule is absolute. No figure appears anywhere in the product without a traceable path back to the line in the source document it came from. AI does the reading, and a person can check any number in seconds. On MicroBooks, the same rule shows up as a document trace from a posted entry back to the receipt that justified it.
That property was adopted for a commercial reason, because a number nobody can defend is worse than no number at all. It happens to be the exact property a modernization program needs. When finance asks why the new system produced a different figure than the old one, the answer cannot be a theory about the migration. It has to be a specific input, a specific rule, and a specific version, retrievable in a minute.
The order that works
Compressed into a sequence a steering committee can hold in its head:
- Inventory the decisions, not just the modules. A module list tells you what to port. A list of the decisions the system makes tells you what has to keep being true.
- Capture behavior as executable tests against the running system, sourced from real production cases. This is the deliverable that makes everything after it verifiable.
- Separate the rules from the accidents. Every surviving oddity gets an owner who says it is required, or it gets retired on the record. Ambiguous branches are a business decision, not an engineering one.
- Then translate, with AI doing the volume and engineers owning the architecture, the data model, and anything touching money, eligibility, or safety.
- Run in parallel until the diff is explained, not until the calendar says stop.
- Cut over in slices, with rollback live and the old system warm.
Steps two and three are the ones under pressure to be skipped, because AI made steps four and six look fast, and skipping the first half is the only way to make the whole thing match the optimistic estimate. That trade is where a modernization program stops being an engineering project and becomes a bet.
Where this starts
Most organizations do not need a two-year roadmap to begin. They need an honest read on one system: what it decides, where the rules actually live, who still understands them, what a behavior harness would cost, and whether the sensible move is to replace it, wrap it, or leave it alone and modernize what surrounds it.
That is what our Assessment produces, in two to four weeks, with interviews and a look at the real code and the real data. Sometimes the finding is that the platform is worth rebuilding. Sometimes it is that the system is fine and the pain is in the three integrations around it. Either way you get a plan you can execute, and an estimate that accounts for the half of the work AI did not make cheaper.
The cost curve genuinely moved. It moved on translation. The proof is still yours to build, and it is still the thing that decides whether the program lands.