This was a lot lighter in content than I expected it to be.
Having survived one rewrite, I'll say that you're sure to drastically underestimate two things: how long it will take, and how many bugs there will be when you're done.
A complete rewrite isn't usually worth the trouble unless you are reaching a bottleneck that you just can't fix. The never-ending bug fixes to your new code will leave you with the same situation that you were trying to fix in the first place. And to top it off you've lost ground since you had to rewrite the base and use your best resources to do it while losing ground to competitors.
Your best bet is to pick sections of pain in your code and refactor them.
I remember that in the '90s Netscape decided that their browser engine code could no longer be used so they had to rewrite it. It took over 2 years and they had to pretty much stop adding new features to their old codebase. They finally delivered the new code, later than they expected. The engine was slower, was full of bugs, and did not add anything to the user experience.
It wasn't the primary reason why they lost the browser war to Microsoft but they used a lot of resources to deliver an inferior product at a time when they had very little room for mistakes.
It was not a complete waste since the code eventually became the first code used by the Mozilla foundation.
"Hype is the plague on the house of software" as Robert Glass put it in "Facts and Fallacies of Software Engineering". A very good citation, the rest is not worth reading.
Hype driven development is for long a big thorn in my eyes. Esp. with rust and raku/perl6.
Having survived one rewrite, I'll say that you're sure to drastically underestimate two things: how long it will take, and how many bugs there will be when you're done.