如何在不停工的情况下切换到新系统？

只要在新系统证明自己之前不关闭旧系统，就能不停工地完成切换：让两套系统处理相同的真实交易并比对输出，测试流程负责人指出的罕见情形，每个模块上线前都要求人工签核，并让旧系统随时可以回退。微软在其迁移执行指南中建议，在切换后的头 24 至 48 小时内监控新系统，并在稳定期内保留源环境作为回退选项。

在第 5 部分中，你已为每个系统选定了路径。本部分不重复我们在不停机实现遗留系统现代化一文中介绍的通用切换方法，而是聚焦新的问题：当新代码由 AI 编写或转换时，应该测试什么。

为什么 AI 转换的代码需要不同的测试

转换工具生成的代码看起来整洁，第一次运行就能跑通，而这恰恰让它的错误难以察觉。错误不会出现在日常业务中，而是出现在每月一次或每年一次的情形里。亚马逊在其大型机应用转换指南中说明，从 COBOL 到 Java 的初次转换会保持相同的行为，随后一个名为 Reforge 的步骤会使用大语言模型，按现代 Java 风格重构代码。COBOL 是一种古老的编程语言，至今仍支撑着许多银行和大型机系统；大型机是大型机构运行核心系统的大型中央服务器。

每一个重写代码的步骤都可能改变某个细节。因此，仅由开发人员读一遍新代码并说看起来没问题是不够的。管理层只有一个问题：在相同数据上，新系统给出的结果是否与旧系统相同？答案来自比对输出，而不是阅读代码。

在相同的真实交易上比对输出

选取业务中一个已结束的期间，例如一个已经结账的月份，把该期间的交易输入新系统，再将输出与旧系统的结果进行比对。需要比对的内容：

• 最终数字：期末的发票总额、余额和库存。
• 报表：管理层依赖的月度报表，逐行比对。
• 发往其他系统的内容：发送给银行、财务或政府门户的文件和消息。
• 拒绝与错误：旧系统拒绝的交易，新系统也必须以同样的理由拒绝。

有些工具帮助准备，而不是代替判断。例如，面向大型机的 AWS Transform 会根据代码属性、作业复杂度和调度路径，分 3 个阶段（配置、确定范围和审查）制定测试计划，然后分 4 个阶段生成从大型机收集测试数据的脚本。但亚马逊在同一份指南中提醒，这些脚本必须在你自己的大型机上、以你团队的权限执行。工具负责准备，你的团队负责执行和判断。对于数据本身的校验，微软建议先比对行数作为快速检查，再用校验和做更深入的检查：校验和是根据数据计算出的数字，哪怕只改动一个字符也会变化。

罕见情形：去问了解它们的人

一个月的真实交易并不包含所有情况。让系统出错的情形，流程负责人比开发人员更清楚：财年年末结账、针对旧发票的部分退货、享受特殊价格的客户、过账后作废的发票、月中入职员工的工资。请每位流程负责人列出他们担心的情形，再把每一项变成一个测试，并在运行前写下预期结果。

这时，你在第 4 部分确认的规则就派上用场了：每一条确认过的规则至少变成一个测试用例。没有测试的规则，你无法确定它是否在转换中保留下来。关于测试类型本身，请参阅我们的软件测试与质量保证指南。

每个模块都要人工签核

这一原则最清晰的公开案例，是 Thought Machine 于 2026 年 9 月 29 日与亚马逊共同宣布的银行系统迁移流程。它分为 4 个阶段：用 AWS Transform 从遗留应用中提取业务逻辑；把重复的变体整合为统一的规格说明；由 AI 智能体生成新的金融产品及其测试套件；最后是验证阶段，在接受任何成果之前，赋予银行工程团队和风险团队明确的签核权。即使签核之后，成果也先进入隔离的沙盒环境做进一步评估，而不是直接投入生产。

对你的公司来说，这个经验既不需要银行，也不需要亚马逊：系统的每个模块，如开票、薪资或库存，上线前都要有两个签名。一个来自技术方，确认所有测试都已执行；一个来自流程负责人，确认结果在业务上正确。微软在切换后也提出同样的要求：由应用负责人确认所有主要功能运行正常。

并行运行与回退计划

并行运行是指两套系统在规定期间内同时运行，旧系统仍是官方基准。开始之前就要确定这个期间何时结束，以及满足什么条件才能结束，例如在一个完整的业务周期内结果一致。然后按如下方式安排切换：

回退计划不是承认失败，而是一份保险。事先写明什么情况会让你回退，例如发票出错或核心流程停摆，由谁做出回退决定，以及用户如何回到旧系统。在稳定期结束之前，不要彻底关闭旧系统。切换后头几周通常会出什么问题，我们在迁移后的头三十天一文中做过说明。

Origami 的观点

我们把切换视为管理决策，而不是技术事件。因此，我们在构建新系统本身之前，先搭建两套系统之间的比对机制，并尽早与流程负责人商定罕见情形及其预期结果，让成功的标准在任何人看到结果之前就已写定。

我们用 AI 加快转换并生成测试，但每个模块的签核始终由你团队中具名的人员负责。想了解我们的工作方式，请查看我们的服务。

本周练习：为每个模块填写切换表

对于你在第 5 部分决定转换或重建的每个系统，在确定任何切换日期之前，与流程负责人一起填写这张表：

以上仅为示例，你的表格会有所不同。关键是：在每个模块都有两位具名签核人和一条书面回退触发条件之前，不要确定切换日期。

下一步

还剩一个问题，每位管理者在把代码和数据交给 AI 工具之前都会问：现代化期间我的数据去了哪里？最后的第 7 部分将回答这个问题，并把整个系列的练习汇总成一份 90 天计划。

资料来源

• 微软：执行迁移，云采用框架——回退标准会议、变更冻结、数据校验、24 至 48 小时监控，以及保留源环境作为回退选项。
• 亚马逊：AWS Transform 中的大型机应用转换——测试计划、测试数据收集脚本和 Reforge 步骤。
• 亚马逊：Thought Machine 与 AWS 关于遗留银行系统迁移的公告——四个阶段以及工程团队和风险团队的签核。
• AWS Transform：官方页面。