Rewrite needs to be seen in context of just fix the old code in place. You are always stoppable and making money, but spend some effort into cleaning up the things you wish you had done differently, enabling tomorrows features, while also have spare "manpower" to use to build new features.
Rewrites often do work out in the long term. However you end up spending 10 years on the rewrite and those are 10 years where the old thing isn't getting as many features (everyone knows it is dead long term so they only invest in the most important features thus allowing your competition time to catch up). Worse those, in 20 years (10 years after the rewrite replaces the old thing) the rewrite is showing age because of things you wish you had done differently.
Which is why I advocate for fixing the old code in place over time. No matter what your best ideas while turn out to be wrong in some way. Architecture decisions that seemed good turn out of have downsides. Languages that go obsolete. APIs everyone uses that you realize should have been done different (If they are only used in one places that is an easy change). Core data structures that no longer meet your needs, but you can't change without touching a million places that update it. You will need a long term effort to fix those mistakes whatever they are. Sure it will take longer to get the old thing to where it needs to be than the rewrite, but you are not saving anything as the new thing will have different mistakes that you will regret in 10 years.
Also the above is in context of a large program. My program to draw names for the family Christmas drawing is easy enough for anyone to write from scratch in an hour so who cares. When your are on a project that costs over 1 billion dollars to write you have different constraints (some of you are on small projects that it is better to write from scratch each time)
Rewrites often do work out in the long term. However you end up spending 10 years on the rewrite and those are 10 years where the old thing isn't getting as many features (everyone knows it is dead long term so they only invest in the most important features thus allowing your competition time to catch up). Worse those, in 20 years (10 years after the rewrite replaces the old thing) the rewrite is showing age because of things you wish you had done differently.
Which is why I advocate for fixing the old code in place over time. No matter what your best ideas while turn out to be wrong in some way. Architecture decisions that seemed good turn out of have downsides. Languages that go obsolete. APIs everyone uses that you realize should have been done different (If they are only used in one places that is an easy change). Core data structures that no longer meet your needs, but you can't change without touching a million places that update it. You will need a long term effort to fix those mistakes whatever they are. Sure it will take longer to get the old thing to where it needs to be than the rewrite, but you are not saving anything as the new thing will have different mistakes that you will regret in 10 years.
Also the above is in context of a large program. My program to draw names for the family Christmas drawing is easy enough for anyone to write from scratch in an hour so who cares. When your are on a project that costs over 1 billion dollars to write you have different constraints (some of you are on small projects that it is better to write from scratch each time)