遗留系统现代化

业务不停摆的遗留系统现代化。

系统仍在支撑业务，但每次改动都越来越慢、越来越险。我们评估现状，挑出值得替换的部分，一块一块地迁移。任何切换之前，数据迁移和回退方案都已确定。

确定现代化改造范围 →

服务概要

遗留系统现代化是在系统持续服务用户的同时，分阶段改变你已拥有并在运营的系统的架构、运行时或平台。服务包括评估、约定的替换或升级顺序、数据迁移和经过验证的切换。

适合这些情况

系统仍能运行，但框架、运行时或架构已经拖慢每一次改动
需要分阶段计划、而不是一次性推倒重写的团队

其他服务可能更合适

需要先收回访问权限和交接知识的供应商更换
COBOL、大型机、SAP 定制或专用嵌入式固件

改造你自己的系统，而不是接手别人的交接

本页面向你已经拥有并在运营的系统，无论是自己团队开发，还是由仍在合作的供应商开发。如果原供应商已经离开，没有人掌握访问权限和系统知识，请先看软件接管；其中的遗留系统评估和限定范围依赖升级仍保留在该页，原有条款不变。只迁移服务器或云账户、不改动应用本身，属于云迁移。对稳定系统的日常更新和修复属于软件维护。

根据评估结果选择改造方式

系统年代久远本身不构成重写的理由。评估会按组件比较各个方案：成本、风险，以及改造期间业务需要继续完成的工作。

渐进式替换

在稳定接口之后，把能力逐项切到新实现上（绞杀者模式）。新路径被证明可靠之前，旧路径一直可用。

框架与运行时升级

升级到仍受支持的语言、框架和库版本。跨度较大的版本升级拆成一系列更小、经过测试的步骤。

平台迁移

以尽量少的代码改动，把应用迁到新的运行时或托管方式，例如容器。只涉及基础设施的迁移按云迁移另行确定范围。

数据迁移

映射新旧数据结构，转换并核对记录，在正式迁移前先在副本上演练。

部件更替期间，业务照常运行

先从阻碍最大、耦合最低的部分开始。每个阶段都需要明确：哪些行为必须保持不变，用于核对这些行为的测试或录制的参考结果，一个切换开关（功能开关、路由规则或发布），回退路径，以及批准切换的负责人。回退到旧版本应用，不一定能撤销数据库或外部系统中的变更，因此数据步骤与代码步骤分开规划。平台是否适配，在评估中确认。

示例验收：新旧路径返回相同结果

针对一项约定的能力，用一组录制的、贴近真实但不含敏感信息的请求，分别调用旧实现和新实现。每一处差异都会被列出，并加以解释或修复。在副本上进行的数据迁移演练会记录行数、选定字段的校验和、被拒绝的记录和耗时。之后在已演练回退的前提下执行正式切换。这是验收方式的示例，不是客户成果，也不保证覆盖所有边界情况。

评估、分阶段交付、交接

每个阶段开始前确认范围和报价。你可以让自己的团队使用评估结果，也可以委托我们实施约定的阶段。

评估
获得组件图、版本与依赖清单、已确认的风险，以及按组件列出方案的分阶段计划。
分阶段交付
每个阶段开始前单独报价，可以是签署的固定范围，也可以纳入月度服务，交付时附带检查和回退方案。
交接
获得更新后的文档、运行手册、已清理的旧代码路径，以及你的团队今后负责运营的清单。

准备访问权限、关键流程和熟悉业务规则的人

我们需要代码仓库和基础设施的访问权限、关键业务流程、已知事件、当前版本清单、数据量，以及了解系统为何如此运行的人。只读访问和生产变更是不同权限。背景阅读：我们如何在不重写的前提下修复架构，以及一个具体案例：遗留 PHP 是升级还是迁移。

// 实证

现有工程项目中的现代化实践

Hyperstate AI 案例记录了把一个 GPU 负载很重的单体拆分为独立服务，并把手动部署改为容器化、编排化的基础设施，而产品界面保持不变。Polity 案例记录了前端与工具链的迁移，以及在功能持续交付的同时整合多个服务的遗留 CI。MyMerch 体现了相反的判断：对一个运行良好的系统做定点改进，不重写。这些案例都不是大型机或 ERP 替换，也不保证其他系统取得相同结果。