The cost that kills the project is rarely in the engineering estimate
The line item that sinks a modernisation project is almost never the one the engineering team quoted. It is the months you pay for two systems at once, and almost nobody puts a number on it before go-live. I have walked into enough stalled rewrites to see the same gap each time, and the pattern is consistent enough that I now assume it before I see the books.
To be clear, plenty of modernisations do fail on technical calls: a big-bang cutover with no rollback, a data migration that corrupts records nobody reconciles, a “monolith to microservices” split that just adds network hops to the same mess. Those are real. A competent team controls for them, and the downtime-free approach exists precisely to keep them from happening. But two failure modes sit above the engineering team, on the budget owner’s desk, and those are the ones that get skipped in scoping, because no one in the room owns them.
Number one: dual-running cost
While you migrate, you run the old system and the new one in parallel. Double licences, double infrastructure, two teams keeping two things alive. Six months of paying twice is a line item, not a footnote, and it lands on the CEO long after the technical estimate looked fine.
Here is how to get the number before it surprises you. Ask whoever owns each cost (licences, hosting, the people) for their honest monthly figure. Multiply by your expected cutover window. Then double the window, because cutovers run long for organisational reasons more than technical ones, and the decision to switch the old system off is the part that stalls. Put that figure on the table before the engineering estimate is locked. Across the modernisations I have costed, running the old system in parallel during a long rewrite adds a meaningful fraction to the total bill, openly estimated, but consistent enough that I plan for it going in. My dual-running cost has never come in under plan.
Number two: undocumented business logic
The old system enforces rules nobody wrote down. On one migration it was a two-hundred-line stored procedure quietly applying a pricing rule the business had forgotten existed. You do not find that in the specification. You find it by sitting with the people who use the system every day.
This is knowledge elicitation, and it is real work, not a workshop. If the warehouse team has built fifteen years of spreadsheet workarounds around the old software, those workarounds are requirements: they encode decisions the business made and then forgot it made. Ignore them and the new system gets bypassed on day one, exactly the way the order system that staff stopped trusting gets routed around. The cost of finding this logic is small. The cost of discovering it in production, after cutover, is not.
Number three: the honest cutover window
The first two numbers depend on the third, which is why it is the one most worth fighting over. The cutover window is how long both systems genuinely run side by side: not the optimistic date on the plan, the honest one. It drives the dual-running total directly, and it is almost always longer than the first estimate, because the thing that ends a parallel run is a human decision to switch the old system off, and that decision carries career risk for whoever makes it. Price the window honestly and the dual-running number stops being a surprise. Price it optimistically and you have simply moved the surprise to later, when it is more expensive.
None of this needs fresh budget
That is the part worth sitting with. Avoiding these failure modes does not require more money. It requires three numbers agreed before anyone commits: the dual-running monthly cost, the honest cutover window, and a list of undocumented rules someone will sign their name to. Get those on one page and the budget becomes a decision made on purpose rather than a number that detonates two quarters in.
If you are scoping a migration and the engineering estimate is the only number on the table, that is the warning sign. Talk to TrueForge and we will help you find the three that actually decide it, before they decide it for you.