开个窗，还是搬个家：用二层小楼讲清 legacy modernization

legacy modernization、legacy migration、replatform、re-architect……市面上这类词一多，人很容易糊涂。我一度也分不清：老系统到底该在原地改，还是整个搬到新平台？后来我用两个「二层小楼」的比方，把这条线捋清楚了。

第一个例子：房子不动，只在临街墙上开个窗

我有一栋二层小楼。二楼住人，一楼因为不用爬楼梯，基本当库房，堆着买回来的各种生活物资。最近我想在一楼临街的墙上开个小窗户，把库房变成小卖店，对外卖货。

房子还是那栋房子：地基、承重墙、二楼的居住习惯，全都不动。我只是在墙上掏了一个窗，让原本只供自家人进出的库房，以受控的方式朝街坊敞开。

这在软件架构里叫 Modernization（现代化改造），具体做法接近 Replatform（局部改造、垫层优化） 或者 Refactor / Encapsulate（封装与重构）。技术上的对应很好理解：银行那套跑在大型机上的 COBOL 老核心不动，只在外面包一层微服务或 API Gateway，手机 App 就能调用老系统里的账户余额，把线上业务开起来。

这种做法的好处是成本低、见效快，核心资产一点没动，老系统却重新长出了商业价值。限制也很明显：窗开得再大，房子还是那栋房子，能接待多少客人、能承多重，取决于原来的地基和承重墙。

第二个例子：搬到 CBD，按商住两用重新规划

还是那栋二层小楼，但我觉得市区的 CBD 更好，于是打算搬家。搬的时候不能像现在这样一楼堆货、二楼住人，而要一开始就规划好：一边做买卖，一边住。

这就是更严格意义上的 Migration（迁移、移植）。现实里，你彻底离开了原来的老地皮——对应到技术上，就是离开老服务器、旧架构环境，换到资源更集中、更现代化的地方，比如上公有云、换 SaaS。新址直接按商住一体设计，等于按新业务重新做架构。

这里还要再分一层：如果只是把老平台上的数据和业务逻辑原样搬到新平台，改动很小，那是纯粹的 migration，像把房子连家具一起吊装到 CBD；如果连内部结构都重做，那就进入 Re-architect（架构重构） 甚至 Replace（推倒重建） 的范畴——把自建机房里的单体系统迁到公有云，同时用微服务、容器化（Docker / K8s）把整个业务重写一遍。

动作大、周期长、成本高，但历史技术债务被彻底甩掉，天花板也打开了。

为什么市面上把它们混着叫

这两个词确实容易混，因为它们是包含关系，不是并列关系。

レガシーマイグレーション（Legacy Migration，遗留系统迁移） 的重点在「搬迁」。目标是把老平台上的数据和业务逻辑，原封不动或者低改动地搬到新平台——像把房子连同家具整体吊装到 CBD。它回答的是「换地址」的问题。

Legacy Modernization（遗留系统现代化） 的重点在「进化」，是一个更大的伞状概念。它不仅包含搬家，也包含在老楼上开窗、接新水管、局部拆除重建。它的终极目标是让老资产具备现代敏捷交付、快速响应新业务的能力。

所以严格说，搬家是现代化的一个子集。开窗改小卖部是现代化；迁去 CBD 重开张，是现代化驱动的彻底迁移与重构。

怎么判断自己该开窗还是搬家

把比方放回软件工程，判断顺序其实就三问。

第一，承重墙还撑不撑得住？如果老系统的核心逻辑依然可靠，只是缺一个对外的通道，那开窗——也就是封装、加一层 API——往往就够了。

第二，限制来自房子，还是来自地皮？如果瓶颈是服务器、运维、弹性、成本这些「地皮」层面的问题，原地装修解决不了，那就得搬。

第三，新业务要的户型，老房子改得出来吗？如果连业务流程和数据模型都对不上，只搬家不够，得重新设计。

这三个动作并不互斥。Modernization 本来就包含 Migration，一个项目里完全可能既开窗、又搬家、还顺手改户型。真正要避免的，是把「搬家」当成万能答案，或者把「开窗」当成终点。

下次再有人跟你提 legacy migration，你可以先反问一句：你说的是搬家，还是连装修带改造？这一问，基本就把概念分清了。