I am on the camp that big rewrites are more often than not a mistake. The real reason behind most rewrites is that writing code is easier than reading code. A system has grown to be too complex to understand, and instead of taking the time to study and understand it, you start writing it from scratch instead. At some point you end up with a new system of perhaps comparable complexity as the original. You now understand that system better, but give it enough time you will get rusty, or new devs will join that do not understand it. Rinse and repeat.
Also many devs underestimate the reasons why code has ended up being smelly. Unaccounted edge cases, legacy system support, time constraints. Who says you won't hit time constraints during the rewrite too?
Of course there are many good reasons for a rewrite too. Being more experienced and a better dev today than you were yesterday when you wrote it, is a great way to clean up whatever amateur mistakes you might have created. Or perhaps the system is inefficient and now you know how to improve it. But incremental updates, and defining the critical code path and making sure that is as robust as possible (eg I am sure you can increase system performance by magnitudes by changing only 10% of the most-often run code), are great ways to start.
Good luck, and I am looking forward lessons learnt too!
The worst is reading the code, understanding it, then re-writing it in $LANGUAGE. Then you have a (buggy) emulation of the original product.
I believe a re-write should be a new product. New accounts will use it, and old ones will be migrated to it. Chances are, the way you did things the first time around wasn't ideal (but you couldn't have known back then), so the process is improving and not just the code.
