I have similar experience: the &quot;incremental rewrite&quot; is usually the most effective tactic to apply. It reduces risk, cuts &quot;time to market&quot; and lets you apply Pareto&#x27;s rule - making the process efficient.<p>Very rarely a rewrite is the answer: for example if the product is functioning poorly, where even low risk changes cause random regressions. Where large system-level changes are needed to make the system work - say because the original developers didn&#x27;t implement authorization checks after the login.html page. Where none of the original developers are available and no-one knows the requirements. Where the system is a hodgepodge of 4 different frameworks including one custom one (whose developer is long gone, leaving 0 documentation or tests behind).<p>In cases like that the software artifacts are a liability; it&#x27;s better to use the assets you&#x27;ve built up (domain knowledge) and develop a new product in parallel. Put the old one in zombie mode and spend two years building the new product with feature parity.<p>There is one other situation where a full rewrite is good: if v1 is a throwaway prototype. However that would never have been put into production for any significant number of users.