“应该重写”很多时候是在表达对旧系统的挫败感，而不是经过验证的决策。代码不整齐不等于关键流程不稳定；新技术栈也可能重新实现同一套不清晰的业务规则。
先定义业务约束
说明当前真正失败的结果：发布过慢、支付不可靠、权限不安全、数据无法追溯，还是维护成本阻碍业务发展。技术方案应服务于这个结果，而不是服务于某个框架偏好。
何时先做稳定
当关键流程频繁失败、部署无法安全回退、监控缺失或访问权限脆弱时，先恢复备份、可重复构建、日志和高风险流程测试，再讨论架构变化。
何时适合重构
当一个模块的行为清楚、有可用测试或样本，并且能找到明确负责人时，可逐个替换边界。重构期间应让旧系统继续作为业务事实来源。
何时考虑重建
当数据模型、安全边界或部署架构已经无法支持业务方向时，重建才可能合理。即使如此，也需要分阶段迁移、并行验证和历史数据处理方案。
防止猜测的问题
- 哪些流程已经稳定，绝不能被破坏？
- 当前问题有哪些可验证证据？
- 更小的边界能否先解决业务约束？
- 新系统上线后由谁维护？
相关服务
需要基于证据制定恢复和架构路线时，可查看现有软件项目接手与稳定。