老网站到了某个阶段会出现这样的状态：改一个字要找三个人，加一个栏目要动十处代码，手机端是新加的皮肤，后台是五年前的技术写的，没人敢碰。
这时候摆在面前的选择是继续补，还是重写。这个问题没有标准答案，但有几个清晰的判断信号。
该考虑重写的信号
符合三条以上，重写的性价比就超过修补了：
- 技术栈已无人维护：找不到会的人，或者框架的官方支持已经结束
- 加新功能的成本异常高：一个小改动要动很多地方
- 手机端是后补的：两套代码或者勉强适配，体验割裂
- 性能问题出在架构上：不是图片没压缩，而是页面生成方式就慢
- 安全漏洞反复出现：底层设计有问题，补丁打不完
- 业务已经变了：原来的数据模型和栏目结构装不下现在的业务
反过来，如果只是设计过时、内容陈旧，那换套皮肤加更新内容就够了，没必要动架构。
重写前必须做的功课
最忌讳的是"照着旧站重新做一遍"。动手之前，先把这些摸清楚：
- 现有所有 URL 清单：用抓取工具导出，这是后面做跳转的依据
- 每个页面的流量与排名：识别高价值页面，重写时要重点保护
- 旧站的数据结构：现有内容怎么迁移，有没有历史数据要保留
- 那些看起来奇怪但有原因的功能：问清楚当初为什么这么做
- 正在运行的第三方集成：支付、短信、ERP 对接，别漏掉
第 4 条最容易被忽略。旧代码里有些诡异的逻辑，往往是当年为了解决某个具体问题加的，不理解就删掉，同样的 bug 会再出现一次。
数据迁移是最难的部分
重写最麻烦的不是写代码，是把老数据搬过去。几个要点：
- 先做映射表：旧字段对应新字段，对不上的怎么处理
- 清洗脏数据：空值、重复、格式混乱的，趁这次整理干净
- 保留原始 ID 或建立对应关系：便于做跳转和后续排查
- 先迁移后校验：跑完对比数量和抽样内容，别等上线才发现少了一半
- 留回滚方案：旧库保留至少一个月
分阶段推进，别一次性切换
风险最低的做法是这样的：
- 第一阶段：新站整体完成后部署在测试环境，全面验收
- 第二阶段：先切一部分流量或者部分栏目，观察一到两周
- 第三阶段：全量切换，同时配置全站 301 跳转，把旧地址指向对应新地址
- 第四阶段：持续监控收录、404、排名变化，及时处理
如果条件允许，保留旧站的只读版本一段时间，作为对照和兜底。
顺手解决的老问题
既然重写，就把以前欠的账一起还了：URL 规范化、结构化数据、图片压缩流程、移动端体验、后台编辑效率。这些在重写时顺手做成本很低，事后再补就又是另一个项目。
重写不是把旧站翻新一遍，而是用新的业务理解重新做一次。如果只是复制，不如不写。
—— 一位主导过三次大规模重构的技术负责人