I’ve been part of several complete rewrites of software projects. I’ve seen it succeed in all cases. Most of the times they were significantly late. Complete rewrites are rare. Smaller ones (refactoring, optimization, architectural change) are more common.
My main advice is to do rewrites gradually. The best way to think about it: keep the ultimate goal in mind at all times, but come up with a gradual strategy. The smaller the steps, the less pervasive they are, the better.
Gradual rewrites are difficult and time consuming. It’s tempting to declare some sort of bankruptcy (performance, outdated UI, buggyness, cost of change), and start from scratch. We tend to be optimistic that complete overhaul will take several days/months/weeks.
Here’s how to make you immune to this false optimism: implant in your mind that rewrites always take three (or more) times longer than you predict, and you won’t be shipping anything during this time. Think of how tired you’ll be after pushing the deadline for two times, and for your code not seeing any usage during this time.
Gradual rewrite is the path for quicker results, and gratification. It will take the same amount of time. You will learn about the system much more than you know now. You will start appreciating good test coverage and architecture.
Architecture is the most important part of the project. Pieces may be replaced, but mechanisms by how they are connected will stay as long as the last piece of the old system is alive.