I led a counter case where a rewrite was very successful. There had been a major component of the architecture that just approached the problem wrong at its inception. Changes that one would have thought should take a few hours or day to make took weeks. And once you dug into the code, you learned why. It lacked adequate tests, proper componentization, error handling and operational visibility. It was far beyond refactoring, it was just ill conceived. It's poor functioning had cascaded into other systems; they were riddled with hacks to compensate for the problem system's deficiencies; technical debt had become a cancer that spread around the architecture. At a certain point, we declared the technical debt had reached technical bankruptcy and acquired buy-in across the organization (execs to engineers) that we needed to start a new code base.

However, part of making the rewrite succeed was sucking it up and doing continued maintenance on the legacy system. It was no fun but it had to be done. Things that couldn't be implemented in a reasonable time with the legacy system but were high priorities were implemented in the new system to assure that the win wasn't just one of purity of essence, it was enhanced functioning. Enough was learned from what worked and what didn't in the legacy system that we had a good deal of clarity on what requirements we wanted to fulfill. The hand wringing over excessive feature creep and other foibles that can make rewrites fail were attacked with discipline.

I've heard of many big rewrites that failed but don't buy the argument that they demonstrate that it can't be done. It can.