客户发来一个压缩包：五年前某团队做的公众号系统，后台能登，但框架是停更的老版本，文档没有，原班人马联系不上。想在上面加会员功能，报价问了一圈没人敢接。老系统升级是微信公众号开发里最难啃也最常见的需求，先判断值不值得救。
三问定生死
一问数据值不值钱：几万条会员数据和订单记录，迁移成本再高也得保住，数据是唯一的不可再生资产。二问代码还有没有救：框架版本是否还能跑在受支持的运行环境上，数据库结构是否清晰，有无基本注释，三样占两样就有渐进改造的余地。三问业务还要走多远：打算再用三年，值得投入改造；半年后整体换系统，打补丁就是浪费。评估时让工程师把系统跑起来通读一遍核心代码，两三天够用，凭压缩包和截图做的评估都不可靠。这道判断题，几乎是每个微信公众号开发维护团队都要面对的。
渐进改造的路子
推荐新旧并行的策略：老系统继续服役，新功能用新框架独立开发，中间通过数据库视图或接口桥接，逐步把核心模块挪到新系统，最后老系统只读归档。切忌推倒重来的豪赌，平行跑三个月，新旧对不上账的地方一点一点磨平，风险小得多。改造顺序上，先动数据层：把混乱的表结构梳理清楚，写好迁移脚本，应用层怎么换都有的接。桥接层的接口文档同步维护，新旧两边的团队每周碰一次，对齐进度和口径。
改造中的三条纪律
- 改造前给数据库做一次完整快照，随时可回退
- 新旧并行期间，同一业务两边口径要对齐
- 每挪一个模块，灰度一周再挪下一个
- 桥接层接口文档同步维护，每周对齐进度
费用结构上提前说清：老系统改造的报价弹性极大，同样的活有人报三万有人报十万，差异在评估深度。要求乙方先出评估报告再谈总价，报告费单独支付也值得，这钱买到的是明明白白的工作量清单，比一口价踏实得多。
上面那个压缩包项目，评估后我们只迁移了会员和订单两个模块到新框架，其余页面保留原样，成本控制在新开发的四成左右，客户第二年顺利加上了积分功能。老系统不是只能重写，会算这笔账的团队才能给出合理的报价。有类似困境的，先让比格网络做一次代码和数据体检，救与不救、怎么救，体检报告里见分晓，报告要包含风险清单和改造成本区间，别只给一个结论。改造要有耐心，快就是慢。
