上周去苏州找个做银行科技的朋友喝酒，他刚熬完三个大夜，眼窝陷得像被人打了两拳。不是做新业务。是给一套跑了19年的核心系统打补丁。说白了，这就是遗留系统改造里最常见的起步环节——不是上来就全拆重写，是先给老棺材钉钉子，怕它当场散架。
先别急着谈重构
很多人一听到遗留系统改造，第一反应就是要上云、要微服务、要把老代码全扔了。真到了现场你就知道，这想法有多天真。
之前接触过一个制造企业的信息部主任，说当年领导拍板要把跑了15年的ERP全换成云原生的，预算批了两千万，做了八个月，上线第一天，车间的报工系统直接卡成PPT。原因说出来都可笑：老系统里存了十年的BOM表，有一半是当年的老员工用半角全角混着录的，还有不少错别字，新系统的校验规则太严，直接把这些数据全拦在门外。
更麻烦的是代码本身。很多老系统的代码，现在能找到的写代码的人，要么退休了，要么去了竞对，剩下的文档，可能就是当年的几个Word，连版本号都对不上。你根本不知道哪行代码藏着哪个隐藏的业务规则——比如某行写着if (status == 3) then 跳过分红计算，你去问所有还在职的老员工，没人记得为啥要加这个判断，直到你翻了三年的业务纠纷台账，才知道当年有个大客户因为这个规则漏算过分红，闹到了总部，最后给了几十万的补偿。你要是上来就把这行代码删了，等着你的就是业务部门的连环投诉。
我见过最极端的例子，某券商的老交易系统，有一段代码是1998年写的，注释里只写了”不要动”三个字，没人知道为啥不能动，但每届运维都默认遵守。你说这是遗留系统的坑？对，但你要是敢把这段代码删了，第二天交易时间出了问题，你担不起这个责任。
双轨跑的成本没人算
很多人算遗留系统改造的预算，只算开发费、服务器费，双轨并行的隐性成本，从来没人往上报。
说白了，你不能直接把老系统停了切新的，万一新系统出点幺蛾子，你得有退路。所以行业里默认的规则是，核心系统切换前，新老系统至少要并行跑3个月，老系统记一套账，新系统记一套账，每个月要逐笔对账，对不上的地方要挨个找原因。
你以为这只是多做点数据核对的活？太天真了。很多企业的信息部本来就没多少人，平时还要应付日常的系统运维、业务部门的临时需求，现在要抽一半的人出来专门做对账，连续几个月连轴转，人都要熬垮。之前有个做保险的客户，改造期间信息部的三个运维，连续两个月没休过周末，最后直接辞了两个。
还有个隐形的成本，是业务部门的抵触。老系统他们用了十几年，闭着眼都能找到哪个按钮在哪，现在换了新系统，界面变了，操作逻辑变了，他们要重新学，还要一边干活一边抽时间填测试数据，谁会乐意？之前有个做零售的客户，改造到一半，门店的店长集体闹到总部，说新系统的库存盘点操作比老系统多了三步，每天下班要多花二十分钟才能做完，最后项目组只能回头给新系统加了个快捷入口，本来已经写完的代码，又改了一周。
这些成本加起来，往往能占到总改造预算的30%以上，但立项的时候，没人会把这些写进预算表。毕竟写进去了，领导可能就觉得项目太贵，不批了。
改造完的系统真的好用吗
很多人觉得，遗留系统改造完，系统就轻了，维护成本就降了，业务迭代速度就快了。真不一定。
比如你把原来的单体系统拆成了二十个微服务，听起来很时髦，但是原来的单体系统出了问题，直接查一个日志就行，现在拆成了二十多个服务，出了问题要顺着调用链查一圈，哪个服务超时了，哪个接口报错了，要是没有成熟的可观测体系，排查问题的时间比原来还长。
还有，你为了兼容老系统的历史脏数据，可能还要在新系统里加不少临时的兼容代码。这些代码写的时候就知道是过渡用的，但是一放就是好几年，最后新系统也变成了新的遗留系统。我见过最离谱的案例，某企业花了三千万改造的系统，上线一年之后，信息部的人说，现在的维护成本比原来老系统还高——原来老系统只需要一个资深的运维就能搞定，现在新系统要五个开发轮班值守，还要配专门的人做监控。
这事没那么玄。很多时候，你以为你在给系统治病，其实是给它换了个更贵的壳，里面的病灶根本没动。
上周跟那个银行的朋友再通电话，他说那个跑了19年的系统，最后还是没全拆，只是把最容易出问题的账务模块拆出来换成了新的，剩下的模块接着跑。他说，领导本来想搞个大新闻，说自己推动了核心系统的全面重构，结果算完实际要花的钱之后，发现比最初的预算多了两倍，直接缩了范围。
说白了，遗留系统改造从来不是什么纯技术问题，是算账的问题。你得算清楚，你改它到底是为了什么，是为了真的降本提效，还是为了给汇报PPT添点好看的内容。要是后者，那不如多花点钱给老系统做个异地备份，比啥都强。