所有用了五年的系统都难用，但不是所有都该重写。 重写是最贵的选项，而且失败率不低——很多团队花一年重写，最后发现新系统缺了一堆「不起眼但每天在用」的功能。
三个判断，先问清楚
第一，改一个功能要多久？ 如果一个小改动要两周以上，或者改 A 功能会弄坏 B 功能，说明架构已经撑不住了。这时候不是代码写得烂，是结构不适合现在的业务。
第二，有没有人读得懂代码？ 原来的开发者走了，现有的人只能「绕开」而不能「修改」，那这套系统已经是黑盒。黑盒系统的维护成本每年都在涨。
第三，数据能不能迁？ 打开数据库看一眼：字段名是 `field1`、`field2`，还是没有主键、没有外键、同一个客户有三条重复记录——那迁移本身就是个大工程。
一个残酷的判断
如果三个问题都是「很糟」，重写的收益最大，但风险也最大——因为你对现有系统的理解可能还不如你以为的深。
重写的真实成本
多数人算重写成本时只算了开发。实际还要加上：
- 数据迁移：清洗、映射、校验，通常占总工作量的两三成
- 并行运行：新旧系统同时跑一段时间的成本和协调
- 员工重新培训：界面全变了，效率会先下降再回升
- 遗漏功能：那些「没人提但每天都在用」的小功能，重写时最容易丢
渐进式改造：更慢但更稳
不推倒，按模块替换。 先把最痛的一块（比如报表）用新架构重做，跑稳了再换下一块，老系统逐步退场。
好处是风险分散，任何时候都有可用的系统；坏处是周期长，而且新旧两套要并存一段时间。 很多企业最后走的是这条路，因为它允许「中途反悔」。
什么时候必须重写
- 技术栈已经没人维护（比如依赖的运行环境停止更新）
- 存在无法修补的安全漏洞
- 业务已经变了，系统结构根本表达不了新流程
- 每次改动都会引入新故障，团队已经不敢动它
什么时候不该重写
- 只是界面难看：换一层界面比换内核便宜得多
- 只是慢一点：先做性能优化，往往能解决八成问题
- 业务本身要变：等业务定型了再重写，否则重写完还得改
- 没有明确的需求清单：这种情况下重写等于重新猜一遍
最后
重写不是技术问题，是一次业务决策。 它要用一年时间和大量预算，去换一个「以后改起来更快」的未来。值不值，取决于你的业务还要跑多少年。