I think it's crucial here to identify the point where a particular architecture is breaking down and no longer serves the needs to find out when you
should rewrite. Oftentimes the bashing of an old codebase occurs not while it's still adequate, but rather when it's still in use long after its expiration date. What starts as a quick hack can survive remarkably long, but sooner or later technical debt makes things so complicated that thinking about a rewrite is probably not the worst thing to do ... if you have the time and money to do so (but if you don't you'll just ink more and more time and money into an inadequate solution that breaks down catastrophically sooner or later).
The best thing probably would be to try to figure out whether you'd hit that point in the near future, so you can start work on the rewrite or overhaul ahead of time instead of being forced to make the new code a rush job as well because everything's breaking down around you.