If the written code has fundamental issues, such as not following basic patterns like SOLID principles or core OOP concepts, it is better to rewrite it from scratch. However, if only specific details need improvement, refactoring is preferable. Overall, the first choice is refactoring, followed by rewriting if necessary.

Rewriting an older codebase is often risky. It may cover many subtle bugs and edge cases that are difficult to unravel. Rewriting means re-exposing all of these issues. Incremental refactoring is often the safer strategy in this case. Of course there are exceptions. For example, if the technology is so outdated that the ongoing maintenance costs of even a refactored codebase will outweigh any short term benefits.

It’s a risk reward thing: I have rarely seen an epic rewrite pulled off successfully, in no small part because the rewrite usually needs to have feature parity with the legacy app that has had years (if not decades) to improve. In the rare cases I’ve seen it succeed, it takes a strategic and intentional commitment from the c-suite to spend upwards of 3x to 5x the annual dev budget of the legacy app in order to get to actually achieve feature parity on a timeline your customer base will tolerate. So to me the decision to do the epic rewrite comes down to the true commitment of the people controlling the budget. As the epic rewrite is usually tough to swallow, I have seen a lot of professional success with incremental strangler strategies