"这套系统太老了，要不要重做"是常见诉求。但重做常常低估了隐性成本——那些跑在系统里的规则，很多只存在于代码和某几个人的记忆里。先回答五个问题再决定。
一、五个必答问题
- 现有系统的数据还能用吗？表结构是否还有参考价值？
- 现有系统的业务规则有文档吗？还是只在代码里？
- 当下的痛点是功能不够，还是性能/体验差？
- 业务模式在未来 3 年会变吗？会变的话，重做等于把赌注押在会变的东西上
- 有没有可靠的回退方案？重做期间老系统要能继续跑
二、"改造"其实是三种程度
| 程度 | 做什么 | 适用症状 |
|---|---|---|
| 界面层改造 | 换前端、调布局、统一交互，后端接口不动 | 逻辑没问题，就是难看、难用、手机上打不开 |
| 局部模块替换 | 把最痛的 1～2 个模块抽出来重写，其余保留 | 大部分能用，个别模块拖后腿 |
| 数据层重构 | 重整表结构与数据流，接口保持兼容 | 加个字段要改多处，报表算不准 |
大多数"想重做"的诉求，落在第一第二种就解决了，成本通常是重做的 20%～40%。
三、重做真正的代价在哪
- 业务规则的重新发现：老系统里那些没写进文档的判断，要在重做过程中一条条捞出来
- 数据迁移：历史数据的清洗、去重、字段映射，往往比开发本身还费时
- 并行期：新旧系统同时运行、数据保持同步的那段时间，人力和风险都是双份
- 用户重新学习：换了系统的适应期，是真实的生产力损失
四、一个务实的判断顺序
先量化痛点
把"难用"翻译成数字：每天多花多少人工、出错率多少、报表要多久
再试最小改造
先做界面层改造，看痛点是否消除
还不够再换模块
逐个替换，每换一个都能独立上线验证
最后才考虑整体重做
并且要求：新旧系统并行期至少覆盖一个完整业务周期
提醒：不管走哪条路，先把老系统的数据库备份出来并确认能恢复。这一步做完了，才有后面所有选项。