在不中断运营的前提下实现遗留系统现代化

几乎每家经营超过十年的企业，都至少有一套作为运营支柱的遗留系统。它可能是多年前由自由职业程序员开发的桌面应用，可能是基于已不再受支持技术的 Web 系统，也可能是一堆只有一个人看得懂的电子表格和宏。系统仍在运行，但越来越难修改、越来越脆弱，维护成本也越来越高。

对遗留系统进行现代化改造的决定常常被推迟，原因是一个合理的担忧：万一运营中途停摆怎么办？本文介绍系统需要现代化的迹象、从最轻量到完全重写的各种策略、保证业务持续运转的渐进式方法、数据处理方式，以及需要避免的错误。

要点

• 现代化并不总是意味着从零重写；不同策略的风险和成本各不相同
• 渐进式方法，即逐块替换系统，对不能停机的系统最为安全
• 先理解并记录遗留系统的行为，包括隐藏的业务规则
• 数据是最重要的资产；从一开始就规划迁移、校验和同步
• 为过渡期设定截止时间，避免永远同时维护两套系统

遗留系统需要现代化的迹象

仅凭使用年限并不足以成为更换系统的理由。稳定、安全且满足需求的老系统可以继续使用。当系统开始阻碍业务发展时，现代化才变得紧迫。以下是最常见的迹象。

• 小改动耗时很长，而且经常破坏其他部分
• 只有一两个人了解系统的工作原理，而且很难找人替代
• 所用技术，例如操作系统、数据库或编程语言，已不再获得安全更新
• 团队需要在办公室外或手机上访问系统，但系统做不到
• 与网店、支付网关或税务应用等其他系统集成很困难甚至无法实现
• 必须把数据导出到电子表格手工处理，才能得到所需报表
• 随着交易量增长，性能不断下降

遗留系统最大的成本往往不会出现在 IT 预算中。它体现为员工花在手工作业上的工时、因系统不支持而无法把握的商机，以及数据丢失或安全事件的风险。就像分散在各处的数据孤岛一样，它在不知不觉中侵蚀效率。

现代化策略的选择

没有适用于所有系统的统一答案。选择取决于代码状况、系统的业务价值、预算和风险承受能力。以下是从最轻量开始的各种选项。

迁移到新的基础设施

把系统原封不动地从旧服务器迁移到云端或新服务器。风险低、速度快，但应用内部的问题没有解决。如果主要问题是硬件老化或办公室服务器不安全，这适合作为第一步。

升级平台

把编程语言、框架和数据库升级到仍受支持的版本，并按需修改代码。这可以消除安全风险、引入现代类库，而对用户来说功能保持不变。

用 API 封装

遗留系统继续运行，但为其增加一层 API，使移动应用、客户门户或仪表盘等新系统能够读写数据。这种方法见效快，常常成为通往渐进式替换的桥梁。我们的 API 集成服务就涵盖这类工作。

渐进式替换

把遗留系统的功能逐一迁移到新系统。已迁移的部分由新系统提供服务，其余部分仍留在旧系统中。随着时间推移，遗留系统不断缩小，直到可以关闭。在软件工程中，这种模式被称为“绞杀者无花果”（strangler fig），得名于缠绕宿主生长并最终取而代之的无花果树。

重写或用成品软件替换

从零重建系统，或用 ERP、SaaS 等成品替换。当遗留系统规模较小、代码已无法维护，或业务流程确实会发生重大变化时，这一选择是合理的。对于大型系统，如果一次性切换，风险最高，因为所有问题都会在切换当天同时爆发。关于自建与采购的权衡，可参阅低代码、无代码还是定制软件。

保证运营不中断的渐进式方法

对于支撑日常运营的系统，渐进式方法通常最安全。以下是核心步骤。

1. 理解并记录遗留系统

在替换任何东西之前，先弄清系统实际在做什么。访谈各部门的用户，观察他们的工作方式，梳理正在使用的报表，并阅读代码以发现隐藏规则，例如特定的价格取整方式或针对特殊客户的例外处理。最终形成一份包含业务规则的功能地图。

2. 用测试锁定行为

编写一组测试，记录遗留系统当前的行为，包括各种场景下的计算结果。这些测试就是基准：除非有意识地决定修改，新系统必须得出相同的数字。没有这个基准，细小的差异往往要等到财务报表对不上时才被发现。

3. 谨慎选择第一块

第一块应当带来实际收益、与其他部分相对独立且风险可控。例如报表模块、供客户查看订单状态的门户，或外勤团队的录入应用。避免从最复杂的核心入手，例如库存计算或会计。

4. 构建中间层

中间层，例如 API 或负责路由请求的网关，决定某个功能由旧系统还是新系统处理。有了这一层，用户无需知道是哪套系统在工作，切换可以按功能逐个进行，出现问题时甚至可以回退。

5. 切换、监控，然后关闭

每一块都逐步切换，例如先在一个分店上线，同时进行监控。稳定之后，再停用遗留系统中的对应部分。最后这一步很重要：如果不停用，两套系统会一直并行运行，成本不断累积。

数据处理：最关键的部分

代码可以重写，但历史数据无法重建。遗留系统中的数据常常存在重复、格式不一致，以及字段用途与名称不符等问题。从一开始就要规划数据处理。

• 数据画像：在制定迁移规则之前，检查数据质量、完整性、重复和异常
• 映射：明确每个旧表和字段在新结构中的对应关系及转换规则
• 过渡期同步：如果两套系统同时运行，要确定每类数据以哪套系统为准
• 对账：定期比较新旧系统之间的合计、余额和记录数
• 归档：确定哪些历史数据完整迁移，哪些只需归档备查

还要确保每一步迁移之前都有经过验证的备份，并制定恢复计划，详见我们关于灾难恢复与业务连续性的文章。

目标架构：不要制造下一个遗留系统

现代化是修复基础的机会，避免新系统在十年后成为负担。一些有用的原则包括：选择流行且社区庞大的技术，把业务逻辑与界面分离，提供有文档的 API，实施自动化测试和一致的发布流程，并编写充分的文档。

没有必要一开始就把系统拆分成许多小服务。对许多中型企业来说，一个结构清晰、模块分明的单体应用反而更容易维护。我们在单体还是微服务一文中解释了这种权衡。

管理人员与变革

遗留系统的用户对每个界面和快捷操作都了如指掌。新系统无论多好，一开始都会让人觉得更慢。从系统调研阶段就让关键用户参与，请他们在每一块切换前进行测试，并在最初几周提供培训和现场支持。要预料到会有一定阻力，并用清晰的理由和看得见的快速成效来化解。

一直以来维护遗留系统的人，是最宝贵的知识来源。要让他们参与项目，而不是把他们边缘化。他们对特殊情况和历史决策的了解可以避免许多错误。

估算成本与进度

在理解遗留系统之前，很难准确估算现代化的成本。因此应把项目分为两个阶段。第一阶段是评估：梳理功能、检查代码和数据，然后制定渐进式计划并按块估算。第二阶段是实施，由于基于真实的发现，其估算要可靠得多。

渐进式方法也让预算更容易安排。每一块都有可以单独评估的成本和收益，您可以根据上一块的结果决定继续、暂停或调整顺序。同时也要把它与“什么都不做”的成本相比较：手工作业工时、安全风险以及错失的机会。

常见错误

• 在不了解遗留系统功能和业务规则的情况下贸然重写
• 同时加入大量新功能，导致范围膨胀、进度拖延
• 忽视数据质量，直到临近切换才发现问题
• 没有设定过渡期截止时间，导致两套系统长期并存
• 长期冻结遗留系统的所有修改，而业务仍需要调整
• 没有准备切换失败时退回遗留系统的预案

结论

遗留系统的现代化不必是一场拿运营冒险的大项目。通过全面理解系统、用测试锁定其行为、逐块迁移功能并认真对待数据，企业可以在每天照常服务客户的同时，转向现代化的技术基础。

关键在于纪律：每个阶段目标清晰、成功标准具体，并承诺在替代部分稳定后真正关闭旧的部分。最终收获的不仅是更安全、更快速的系统，还有让企业在未来更灵活应变的能力。