There is a reason your industry peers all seem to have a modernization horror story, and it isn't bad luck. The legacy modernization market has a structural problem: the worse a project goes, the more money the vendor makes. Once you see that, everything else — the missed deadlines, the ballooning invoices, the promises that quietly evaporate — stops being surprising and starts being predictable.
The pitch
It always starts the same way. A confident deck. A "proven accelerator." A fixed-ish price with an 18-to-24-month timeline. Reference logos you can't call. And the line that should be a warning label: "we'll handle discovery as we go."
Note what is not in the pitch: a demonstration on your code and your data. The pitch is about their process, their methodology, their partnership tier. Proof is scheduled for later — usually a phase called something like "validation," conveniently after the contract is signed and the team is billing.
The unravel
The sequence is so consistent you can set a calendar by it:
- Discovery discovers things. The estimate was built on a code count, not on behavior. Now there are "undocumented dependencies" — which is to say, the system does what the system does, and nobody priced that in. First change order.
- The freeze that can't hold. The plan assumed your business would stop changing the legacy system for two years. Your business did not stop. Every legacy change now has to be re-implemented on the target — a treadmill the schedule never modeled.
- Fixed price becomes time-and-materials. Somewhere around the first slipped milestone, the contract gets "restructured to reflect project realities." The vendor's downside risk transfers to you, retroactively.
- The eternal parallel run. The new system runs alongside the old, and the outputs don't match. Not wildly — almost. A penny here, a date-edge there, a rounding rule nobody remembered. "Almost" is the most expensive word in modernization, because reconciling almost-matches burns months of subject-matter-expert time you were told you wouldn't need.
- The quiet descope. Batch jobs "out of scope." Reports "to be retired anyway." The definition of done shrinks until the project can be declared a success at something, and the remainder becomes Phase 2 — priced separately.
Why the incentives reward this
Here is the uncomfortable arithmetic. A modernization that lands on time is one invoice. A modernization that struggles is years of invoices — extended teams, rescue specialists, remediation phases. And when a project finally collapses, the vendor who failed is rarely the one who pays: a different consultancy gets hired to rescue it, at rescue rates, and the cycle restarts with the same incentive structure. The rescue-of-the-rescue is the most profitable engagement in the industry.
Meanwhile you are a hostage of your own sunk costs. Three years and eight figures in, nobody wants to be the executive who writes it off. So the checks keep clearing. This is not a hidden conspiracy; it is just what happens when you pay for effort in a market where only outcomes matter.
None of this is speculation about shadowy actors — the public record is full of it. The UK bank TSB's 2018 migration went live before testing supported it and locked customers out for weeks; the independent post-mortem the bank itself commissioned said as much. Queensland Health's payroll replacement became one of the most expensive IT failures ever publicly documented, with a government inquiry to match. The U.S. GAO has spent decades cataloguing federal modernization programs that ran years late and multiples over budget. The pattern is not rare. The pattern is the norm.
And now: the AI rebrand
The newest coat of paint on the same machine is "AI will translate your COBOL." Understand what that means operationally: a probabilistic system, which by construction can produce different output for the same input, is being pointed at code whose entire value is that it produces exactly the same output for the same input, every time, for forty years. When the translation is wrong in a way that compiles, you will not find out at the demo. You will find out at month-end close.
AI is a genuinely useful assistant for understanding a legacy estate. As the conversion path itself for systems that move money? You are buying a lottery ticket and calling it a methodology.
The demand that ends the grift
All of this survives on one thing: proof deferred until after commitment. So invert it. Before any contract, any deposit, any "discovery phase," make one demand:
Take a real slice of our system — our programs, our copybooks, our production-shaped data — and show us the modernized version producing byte-for-byte identical output, in an environment we can rerun ourselves.
A vendor with a real pipeline can do this in days, and will be glad you asked, because it ends their competition. A vendor without one will explain why that isn't how it works, why their methodology requires alignment workshops first, why proof comes in Phase 3. That explanation is your answer.
Deadlines don't slip at the end of a project. They slip at the beginning — the day you accept promises where proof should be.