上周跟一个做银行核心系统的老工程师吃饭，他扒拉着碗里的盖饭说，他们那套跑了17年的核心系统，现在改个支付接口要走三层审批。写代码的人换了三波，谁也不敢碰底层的交易逻辑。动一下？怕半夜三点被告警电话炸醒。
先搞清楚你要改的到底是什么
很多人一提遗留系统改造，第一反应就是把老代码全扔了，上云，换微服务，搞全套云原生。
错。
真到现场你会发现，那堆写在2006年的Java代码，跑在锈迹斑斑的物理机上，连接的是当年本地部署的存储阵列，甚至连完整的文档都散在不同人的私人U盘里。你删了任何一个不起眼的方法，可能对应的是某个郊区支行二十年前手写的特殊业务流程，人家现在还在给老年客户办业务呢。
绝大多数遗留系统的核心价值，从来不是技术架构，是沉淀了十几年甚至几十年的、没被写进正式文档的业务规则。
我见过最离谱的项目，上来就给企业算ROI，说重构完能节省30%的运维成本，结果上线第一个月，把老系统里藏了十年的“老年客户无密码取款”的特殊规则给漏了，半个月接了三百多笔投诉，整改的钱比三年省的运维费还多。
亏不亏？太亏了。
别上来就谈技术先进性。你要先蹲在业务部门待一周，把所有藏在代码里的特殊规则扒出来，列成清单，再谈怎么改。
拆系统比写系统难十倍
很多人觉得拆单体嘛，按业务边界划成一个个服务，再配个注册中心，不就完事了。
麻烦在于，老系统的代码边界，跟现实里的业务边界根本对不上。
当年为了赶项目进度，写的代码里，交易模块藏着客户积分计算的逻辑，积分模块嵌着风控的校验规则，风控模块里还混着渠道对接的特殊判断。你顺着代码找边界，找着找着就绕进死胡同——一个方法被十几个地方调用，你根本不知道动了它会影响哪块业务。
遗留系统改造没有银弹，所有拍胸脯说三个月全量重构完的方案，最后都会变成半夜三点的紧急故障。
靠谱的做法从来不是一口气把整个系统拆碎。先挑那些迭代慢、出问题多的模块，单独摘出来做成独立服务，跟老系统做双写，跑三个月，对比两边的数据没差，再慢慢切流量。
我接触过的团队里，有个很有意思的操作：专门把当年写这套老系统的退休老工程师请回来，蹲在会议室里对着老代码一行行讲。哪个分支是2015年为了应对监管临时加的，哪个接口是给某家重点大客户单独开的，哪个判断逻辑是当年为了绕开硬件性能限制写的。没人觉得这掉价。毕竟真出了问题，翻十份文档不如找当年写代码的人唠半小时。
算清楚你要为改造付的隐形成本
很多项目做预算的时候，只算了开发人力和云资源采购的钱，根本没算那些藏在水面下的隐形成本。
比如老系统上跑的十几个外围对接方，有银行的清算接口，有税务的申报通道，有合作方的支付链路。你每改一个核心接口，就得挨个跟对方对参数，联调，测试，这个周期有时候比写代码本身还长。
还有内部的一线操作人员。他们用了十几年老系统，习惯了原来的操作路径，你改个按钮位置，人家都要找过来提意见，更别说换整套交互逻辑了。
别不信。
我之前跟进过一个制造企业的改造项目，光跟仓储部门的老仓管聊操作习惯，就花了两周。人家说原来的老系统点三下就能完成出库，你新系统要点五下，一天出几千单货，多按两下手指都疼。你要是硬推，最后系统上线了人家还是绕回去用老客户端，你这几百万的投入不就打了水漂？
很多人吐槽遗留系统改造是“带着镣铐跳舞”，其实这事没那么玄。你不用追求把所有老代码都换成最新的框架，只要能让业务跑得更顺，出问题的时候能快速定位，新需求加的时候不用翻半天积灰的老代码，就算成了。
昨天那个跟我吃饭的老工程师说，他们现在的改造节奏是，每个月摘一个小模块，不赶进度，不冲KPI。半年下来，改了六个模块，现在运维告警少了一半，新功能上线的时间从原来的两周缩到三天。
他夹了一块糖醋排骨说，急什么。那套系统跑了二十年，我们陪它慢慢换零件，不也挺好。