改版时技术方常会建议"这套系统太老了，换个新的吧"。这个建议可能是对的，也可能是因为他们只会新技术。怎么判断？
先问老系统到底哪里不行
把问题具体化，别停留在"太老"这种感受：
- 找不到人维护：原开发失联，或者市场上会的人太少
- 官方已停止支持：框架或语言版本不再更新，有安全风险
- 功能加不上：业务需要的能力，现有系统实现不了或者代价极高
- 性能瓶颈无法突破：架构限制，优化空间已经耗尽
- 服务器环境要下线：运行环境本身要淘汰
如果只是"界面不好改"或者"代码写得乱"，那属于可以忍受的范围，不必为此换栈。
换栈的真实成本
要考虑的不只是开发费用：
- 数据迁移：结构不同，映射和清洗的工作量可能超过预期
- 功能重写：老系统里那些看起来奇怪但有用的逻辑，往往没人说得清
- 团队学习成本：内部人员要重新熟悉后台
- 并行期维护：过渡阶段两套系统都要管
- 风险敞口：新系统的稳定性需要时间验证
第 2 条最容易被低估。老系统里的怪异逻辑，通常是当年为了解决某个具体问题加的，重写时不知道背景，同样的坑会再踩一次。
建议换的情况
- 安全风险已经无法忽视：系统停更多年，漏洞公告频发
- 业务模式变了：现有数据模型完全装不下
- 要做的改造超过重做：改动量估算下来接近重写
- 有长期技术团队：换完之后有人持续维护
建议沿用的情况
- 系统稳定，只是界面旧：换模板即可，不必动底层
- 没有专职技术：熟悉的系统比"更好"的系统重要
- 预算和时间紧张：换栈会让周期明显拉长
- 网站规模小：投入产出比不合适
中间路线：渐进替换
不必一次性切换，可以这样过渡：
- 保留后端，重做前端：用户体验改善明显，风险可控
- 新功能用新栈，老功能保留：通过接口或反向代理整合在一起
- 按栏目逐步迁移：先迁一个栏目验证，再推开
其中第 1 条在改版中最实用。用户能感知的变化大多在前端，而后端数据结构和业务逻辑保持稳定，风险最小。
选新栈时看什么
如果决定换，选型标准按重要性排：
- 团队是否熟悉：这是第一位的
- 招人是否容易：冷门技术两年后会变成新的"老系统"
- 社区是否活跃：遇到问题能不能搜到答案
- 生态是否够用：常用功能有没有成熟方案
- 生命周期：官方是否还在积极维护
别忘了问一句
如果换栈，源码和部署文档的归属要写进合同。有些平台型产品在上面开发的网站，源码无法独立部署，等于把自己锁死在一家供应商上。这次改版想换，下次就换不动了。
技术栈是手段不是目的。能支撑业务、有人维护、成本可控，就是合适的选择。
—— 一位做过多次系统迁移的技术总监