Most stalled modernisations follow the same anatomy, regardless of industry. The number changes. The shape of where it went does not.
Key takeaways
- The largest cost on a stalled rebuild is rarely the new code — it's the time spent re-discovering what the old system actually does, because nobody wrote it down.
- Most legacy systems have accreted business rules that exist nowhere except in the code itself — and finding them by reading, by hand, is what blows out the timeline.
- Projects stall less from bad engineering and more from discovery running long enough that the budget and the appetite both run out at the same time.
- AI changes the economics of the discovery phase specifically, not the build phase — which is where most of the stalled money actually went.
The bill nobody itemises up front
A modernisation quote almost always leads with the build: new architecture, new stack, migration plan, go-live date. What it rarely itemises honestly is discovery — the phase where the team works out what the existing system actually does, as opposed to what the documentation says it does, which is frequently nothing, or wrong. On a system old enough to need modernising, discovery is usually the largest line item in the project, and it is the one most consistently underestimated at quoting time.
Where the rules actually live
Every system old enough to need rebuilding has accumulated business logic that exists only in the code: a tax exemption added for one client in 2014, a rounding rule that compensates for a bug in a payment gateway that was itself replaced years ago, an approval workflow that only triggers under a combination of conditions nobody currently at the organisation remembers deciding on. None of this is in the requirements document, because it was never a requirement — it was a patch, applied under deadline, that became load-bearing. Finding these by reading code, line by line, with the people who wrote it long gone, is genuinely slow work. It is also exactly the work that determines whether the new system is safe to switch over to.
Why the stall happens where it happens
Projects rarely stall because the new code doesn't work. They stall because discovery runs three, four, five months past the estimate, the budget originally set aside for build gets quietly reallocated to cover it, and by the time the team is ready to actually build, there isn't enough runway left to finish, and there isn't enough trust left internally to ask for more. The $1.4M figure is not unusual for a mid-sized system rebuild that stalls at this point — and the majority of it is typically sunk into discovery and false-start build cycles, not into a working replacement.
What changes when AI does the archaeology
The part of this problem that AI actually helps with is narrow and specific: reading large volumes of undocumented legacy code quickly, surfacing the business rules buried in it, and flagging where behaviour looks intentional versus accidental, for a human to confirm. It does not replace the judgement call of "is this rule actually still needed" — that is still a conversation with people who understand the business. What it does is compress the weeks of manual code archaeology that conversation depends on, so discovery finishes in the time originally budgeted for it, instead of eating into the time budgeted for the build.
The question worth asking before you start
If you are pricing a modernisation, ask for the discovery estimate separately from the build estimate, and ask how confident the vendor is in it. A vendor who cannot separate the two, or who waves the question away, is quoting you the build price and hoping discovery fits inside it. It usually doesn't.
Outcome-priced from day one
See what this would cost at Effektiv pace.
Pick a project that finished or stalled. Show us a quote you've received or an invoice you've paid. We'll price the same scope on outcomes, not hours.