Turning one piece of software into another is something which offers a spectrum of techniques which range from micro-refactors up to full rewrites. If you find

Turning one piece of software into another is something which offers a spectrum of techniques which range from micro-refactors up to full rewrites. If you find yourself reaching for the full rewrite option, you should realize you have suddenly reached to the very far, far end of the spectrum of options and are basically taking an extreme viewpoint. If you haven't gamed out and really tried to rule out options across the entire spectrum, you've failed -- not just because you've been negligent in terms of planning and trying to make the best choice for your organization/team, but also because if you do end up doing the rewrite, you've made a specific choice that, unlike most others, infuses a large amount of existential risk to the organization and product. In the case of a full re-write, there really must be no other way to accomplish the goal. How many rewrites happen when there was literally no other way? Engineers seem to have a bottomless well of creativity when it comes to solving problems, but that creativity often evaporates when focused on the problem specifically of "How the hell do we get from A to B without a rewrite?" No pain, no gain.