Re-architect vs Rebuild
Restructuring an existing system incrementally versus writing a replacement from scratch — and the strong evidence that incremental wins.
Re-architecting keeps the system running and changes its structure in steps: extract a module, introduce a boundary, replace a component. Each step is verifiable and reversible, and the business keeps getting changes throughout.
Rebuilding starts fresh. It is attractive because greenfield work is pleasant and the existing code is unpleasant, and it fails at a well-documented rate for reasons that recur: the old system encodes years of undocumented business rules and edge cases that nobody can enumerate; it keeps changing while the replacement is built, so the target moves; and there is no value delivered until cutover, so the project is politically fragile for its entire life.
Rebuild is defensible in narrow cases: the technology is genuinely unsupportable, the domain has changed so much that the old model is wrong rather than merely ugly, or the system is small enough to be replaced in a few months.
Otherwise: strangler fig, one capability at a time.