This is 100% correct. We're in the process of doing this now with our products (and our internal systems, also), and it works well.

When you have products and systems that have been around for a decade or more, major portions of them become outdated and need to be rewritten (or largely rewritten, the two are synonymous to me). Best practices in crypto change, operating systems and hardware improve/change, etc., and if you want to keep generating value, you had better change along with it. You can see where organizations don't do this: the developers force weird constraints on IT like needing to use old, obsolete versions of operating systems because the software won't run on newer versions.

Along these lines, one of the problems that I think exists with the software industry today is an inability among developers to recognize that software sticks around a lot longer than one might originally envision. And this phenomenon only gets worse (better, for the end user) as the value provided by the software increases. It's a bit of a Faustian bargain: everyone wants their software to be used and provide value, but often don't realize the "soft commitments" being made in the background that can tie you (or the business) to the code for years (or decades).

It makes me think of a dual of modular system design, a rewrite should aim at finding or validating minimal interfaces so a subsystem can be rewritten (the goal of modules I believe) at minimal cost and uncertainty.

I totally agree with you. In most of the cases this is the most reasonable strategy, unless you really understand what you do. A lot of good code bases live this way. There are usually too many things contributed to existing code. A complete rewrite worth it only when you know for sure, that you can throw away most of the details and nuances of the existing code.

Yepp, exactly. If done right, sometimes even the project owners don't realize that a rewrite is happening.

Incremental rewrite isn’t a rewrite at all. It is the better choice though. It is worth noting that refactoring and improving an area of the code without a need to change it or build new features on it is also wasteful.

Your comment is great except for the first sentence. Maybe you could elaborate on what you mean, but of course an incremental rewrite is a rewrite. All rewrites are incremental, the proposal is to choose the order of increments of a system rewrite such that it is fully working both before and after each increment, rather than start from scratch and wait to find out if the full system will work until and have feature parity after all increments are complete. I’d guess you already knew that, and just have a notion that the word “rewrite” means it needs to be from scratch and all at once for some reason?

I’m just trying to be absolute on the fact that incremental change of a single running system is more efficient and shouldn’t be confused with ‘rewrite’ projects where a second system, that is not used by the business yet, is developed while the business continue to use the ‘old’ one.

Calling incremental improvement a form of rewrite gives it a bad name :)

I’d argue that rewrites that are a second system that (hopefully) eventually get deployed once the features exceed current system is not incremental at all, but is instead Big Bang.

Even if the features of second system are built incrementally, if the business aren’t using it until it is finished then it is Big Bang.

Semantics. see Ship of Theseus

If the plan is to change all the parts one by one until done, it's a rewrite. If the parts are changed one by one for independent reasons, it's just code evolution.