&gt;<i>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.</i><p>In two years your devs should be able to understand the existing code, fix the auth problems, and excise the worst of the code and hodgepodge framework mess. If they can&#x27;t, then they certainly can&#x27;t maintain the old system while building a replacement.<p>If you can&#x27;t understand the old code, you can&#x27;t replace it. If you don&#x27;t understand the requirements, I&#x27;m not sure you can even maintain the existing system. It shouldn&#x27;t take two years to add auth, or remove an unsupported framework.<p>This is the textbook case of when a rewrite will fail, because the scope is not just too big, but unknown (because you don&#x27;t even understand the requirements). The choice to rewrite in this situation is not logical. It&#x27;s emotional. The existing system is a mess, and the fix seems so difficult. But the rewrite estimate is likely poor because you don&#x27;t actually understand the system you&#x27;re rebuilding, and even if it&#x27;s an accurate estimate you lose two years guaranteed just to ship feature parity. You can make a whole lot of improvements to a codebase in two years while also shipping features.