This is madness. There's no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. You can't just wave away those realities with "think about the downsides".<p>I have participated in a few (small) rewrites that were successful, and this would be my advice: Don't rewrite an entire project at once. Pick off smaller features first, get a feel for what your new approach will be like before you commit to the big stuff. This will often mean you have to migrate from a monolithic architecture to a services architecture first. This means your project will grow in complexity first. If you're confused about why a project first grows in complexity before shrinking, watch "All the little things" by Sandi Metz, it's the greatest programming talk ever recorded. If your rewrite gets stuck after adding all of that complexity, then you've played yourself. Worst thing that can happen is you rewrite your entire project, some users or customers start using the new project, but you've failed to rewrite everything and some chunk of your users are still using the old codebase. Now you've got twice as much code to maintain.<p>Before you start a rewrite, consider refactoring and rearchitecting the old codebase, there might be a gem in there that just needs some love and attention.<p>That said there definitely are famous successful rewrites, and I think web application backends are especially suitable for rewrites. Most famous are Twitter and LinkedIn, Twitter going from a relational database backend to a more appropriate fan out message queue based backend allowing them to scale beyond imagination. LinkedIn going from a big rails monolith to super fast node.js microservices reducing their hardware costs a hundred fold if stories are to be believed.