Why Your Legacy System Rewrite Keeps Failing

There's a specific kind of scar tissue we encounter in discovery calls: the company that has already tried to replace its legacy system — sometimes twice — and watched the project stall, balloon, or quietly get abandoned while the twenty-year-old system kept running out of spite. The instinct is to blame the technology or the vendor. The real causes are more predictable, and more fixable.

Failure mode #1: rewriting the mystery

Legacy systems encode decades of business decisions nobody wrote down — the surcharge for one awkward customer, the tax edge case from 2009, the reason invoices round the way they do. Teams that rewrite from the spec fail because the spec doesn't exist; the system is the spec. The fix is archaeological: mine the old system's actual behavior and data before writing a line of the new one.

Failure mode #2: the big bang

The all-at-once cutover is the most seductive mistake in software. It feels decisive; it is actually a bet-the-company gamble on hundreds of unknowns behaving on the same weekend. Successful replacements run the new system in strangler-fig slices — one workflow, one department, one location at a time — with the old system as the safety net until each slice earns trust.

Failure mode #3: nobody owns the decisions

A rewrite surfaces hundreds of small questions: keep this behavior or fix it? Every unanswered question stalls a developer. Projects die when decision-making is a committee that meets biweekly. They succeed when one empowered product owner sits close enough to the team to answer daily.

None of these fixes are glamorous. All of them are the difference between attempt three succeeding and attempt three becoming the next scar story.