Actually, what that piece underpins is not that you shouldn't do rewrites, but that you shouldn't do that with the expense of the developer resources of your le

Actually, what that piece underpins is not that you shouldn't do rewrites, but that you shouldn't do that with the expense of the developer resources of your legacy application, you shouldn't put your old product "on hold" for the period of the rewrite, nor should you pretend that you are modifying the old product, but that rewrite effectively always results in a new product, and you shouldn't except that you can hotswap the new product with the old one. The age old maxim "sell old products to old customers, and new products to new customers" works pretty well here as well. How to rewrite the product if all your experts are tied up in the old product is a different question entirely. For example of industry that seems to be in perpetual rewrite is the gaming industry. But they don't rewrite the old games, the develop new products using partly the existing concepts and software modules. This product based view also tells you something: when in business, you should never do a rewrite out of purely technical aesthetic reasons, but because of concrete measurable business goals.