老系统改造最常见的两个极端：要么不敢动，一年拖一年，直到厂商倒闭、技术栈无人能维护；要么推倒重来，预算翻三倍、数据迁丢一半。中间路线是有的：接口包裹、模块替换、数据迁移三步走，每一步都能独立停下来评估，风险和节奏都可控。
一、第一步：接口包裹，先立防腐层
给老系统外面包一层统一接口服务，对内调用老系统数据库视图或原有接口，对外暴露标准接口并统一鉴权。好处有三个：新功能只对接包裹层，老系统一行不改；鉴权与日志在包裹层统一收口；将来替换任何模块，对外接口不变。工作量参考：单个接口包裹 2 至 5 天含联调。包裹层独立进程部署，与老系统故障隔离，老系统重启不影响新功能。
二、第二步：模块替换，按价值排序逐个换
替换顺序由外而内：先换报表与查询类，风险最低；双跑期间老系统仍是唯一权威源，新系统只读不写，比对脚本每天早 6 点自动生成差异报告，差异连续三天不收敛就暂停该模块的替换。再换订场、报名等前台业务；最后换核心交易与积分。每个模块采用双跑比对：新老系统并行两周，每日比对关键数据，差异率低于 0.1% 才切流量。切流按 10%、50%、100% 三档灰度，每档观察 3 天。原系统没有文档就先做逆向梳理，用两周把表结构与关键逻辑画出来，这笔钱不能省。
三、第三步：数据迁移，先对账再切流
迁移分三段：全量、增量、停机切换。全量前先跑对账脚本，核对三类：总数、关键金额字段、最近 30 天抽样明细，三类都对上才继续。增量期双写或订阅日志，切换窗口选业务低谷，保留 48 小时回滚窗口。切换后一周内每日对账，异常立即回滚。迁移脚本要留版本，第一次跑通后先在备份库重放一次，验证可重复执行。
四、成本与边界：什么时候不值得改
包裹与替换的人工投入约为原系统开发成本的 60% 至 80%：低于这个比例通常意味着改得不彻底，高于则不如重写。三种情况建议直接重写核心：原系统文档全失且无原开发人员、技术栈已无人能维护、数据量或并发超出原设计两个数量级。重写也沿用包裹层思路，老系统先当数据源供养半年再退役，业务不中断。
五、给技术负责人的三条建议
- 改造项目按月出版本，每月一个可验收的小目标，不允许连续两个月没有可演示产出；
- 监控先行：包裹层上线前把关键接口成功率与延迟监控补齐，否则改动等于盲飞；
- 数据库只增不改，老表结构保留，新字段建扩展表，切流完成一年后再做清理。