上周跟一个城商行的技术负责人喝咖啡，他说刚批了两千万的预算做核心系统替换，方案报上去三个月，现在卡在上周的联调环节——老系统跑了19年，没人说清那200多段存储过程到底管着哪些对账逻辑。
他说之前有个外部团队刚进场的时候，拍着胸脯说两周就能完成全量代码梳理，结果碰了老系统里一段没人在意的批处理逻辑，第二天全网点的活期取款多吐了三百万，追了三天才把账平回来。
先别急着拆老系统
很多人对遗留系统改造的第一反应，就是赶紧把老掉牙的系统拆了换全新的，好像老系统是个埋在地下的炸弹，多放一天就多一分风险。
真不是。
大部分遗留系统的风险根本不在代码本身，而在没人摸得透的隐性规则。
这些规则从来不会出现在正式的需求文档里，也不会有什么架构图能把它标清楚。可能是当年某个网点因为老人取养老金要优先排队，特意在系统里加的判断；可能是某个财务岗因为月末对账的特殊要求，攒了十年的手工调整逻辑；甚至可能是二十年前某个开发为了测试方便，留的一个没删的后门参数。
就拿那个城商行的老系统来说，现在翻遍所有能找到的文档，都找不到当年那个后门参数的说明，最后还是找了个退休快六年的老开发，翻了他当年的私人工作笔记，才知道那个参数是用来跳过节假日的对账校验的——当年是因为系统上线赶上春节，网点没人值班，怕跑批失败影响第二天开门，特意加的。
你说这种逻辑，靠几轮访谈能挖出来？
没人扛得住把这些逻辑碰坏的责任。
别把改造做成换壳工程
不过话说回来，也不是所有顶着遗留系统改造名头的项目，真的在解决实际问题。
我见过太多所谓的改造，最后就是给老系统换个皮。把原来的灰扑扑的Web页面换成现在流行的深色模式，加几个动效，后端还是跑在2008年版本的Windows服务器上，甚至原来的Cobol代码一行都没动，只是套了个API网关把前端的请求转过去。
有个制造企业的项目，花了快一千万，最后给领导汇报的时候，新界面确实好看，点个按钮等三秒就能弹出结果，一问后端链路，还是原来那套跑了16年的老程序。说白了，这就是给老系统穿了件印着“数字化”字样的新外套。
真正的改造要算清楚每一笔业务链路的迁移成本，而不是盯着界面好不好看。
麻烦在于，很多项目的预算本来就是按“转型展示”的名头申请的，要的就是能放进汇报PPT的截图、能对外宣传的成果，根本没人关心老系统里跑了十几年的生产调度逻辑，会不会在迁移的时候出问题。之前碰到个做汽车零部件的工厂，改造完新系统上线第一天，车间的排产顺序直接乱了——原来的老系统会根据每个班组的设备老化程度调整加工时长，新系统里根本没这个逻辑，因为需求调研的时候没人想起这茬，毕竟车间主任换了三任，现在的主任根本不知道十年前老系统里加过这个判断。
花了大价钱做的改造，最后连车间正常生产都影响了，图啥呢。
留够兜底的缓冲带
还有个最容易踩的坑，就是改造的时候太追求“一次性切流”的爽感。
我见过最离谱的一个项目，上线当天项目组直接把老系统的服务器格式化了——他们说怕有人偷偷切回老系统，影响项目的“上线成功率”。结果当天下午新系统出了个bug，把客户的订单金额算错了三倍，想切回去的时候，连服务器的登录密码都找不全，最后全公司加班加了48小时，才把所有错账捋平。
遗留系统改造最忌讳的就是把退路提前堵死。
很多人觉得改造就要快，要赶在年底的考核节点前把新系统切完，要给领导看“立竿见影”的效果。但你想想，一个跑了十几年的老系统，承载的是企业所有的历史业务数据，是无数业务岗的同事一点点磨出来的操作习惯，你用两周时间就想把它彻底换掉，本身就是对业务不负责。
上次聊到最后，那个城商行的技术负责人说，他们现在把原来的全量替换计划全推翻了。不着急拆老系统，也不着急换界面，先把老系统里的200多段存储过程逐段跑通，每跑通一段就把对应的逻辑拆出来放到新系统里，两边并行跑三个月，对账没差异了再切这部分的流量。
他说之前总觉得慢就是效率低，现在发现，慢一点反而省了好多之前踩过的坑。
其实遗留系统改造从来没有什么标准答案，不用非要追着最流行的技术栈跑，也不用非要搞什么“一步到位”的宏大规划。把藏在老系统里的隐性逻辑摸透，把每一步的风险兜住，比什么都强。