更换业务系统：何时适合让新旧系统并行运行？

在替换期间保留旧业务系统，有助于核对结果，也可以分阶段转移工作。在批准这段并行期之前，应先明确四项内容：具体目的、权威记录的归属、负责调查差异的人，以及双方同意的结束条件。

对 CEO、运营负责人或财务总监而言，这项决策关系到企业如何维护准确记录并完成日常工作。“两个系统都会运行”仍留下太多未决事项。方案需要说明每个系统承担什么工作、员工使用哪个系统，以及这种临时安排会产生哪些成本。

“两个系统并行”有三种不同含义

比较输出结果。一个系统继续执行实际业务操作，替换系统则计算结果供团队核对。例如，在假设的会计系统替换场景中，团队可以针对相同的已定义期间和输入比较报表，同时由现有系统继续开具发票。比较计算结果时，必须避免意外重复开具发票、支付款项、创建订单或发送邮件。

应约定哪些差异需要关注，以及由谁调查。总额相同，仍可能掩盖单条记录、舍入规则或时间安排上的差异。数据复制成功也不能回答另一个问题：员工能否完成所需流程，包括更正和例外情况？

分阶段移交责任。将一项明确的功能或一组客户转移到新系统，同时让其他工作继续留在旧系统。每个阶段都需要清楚说明员工在哪里录入变更、报表从哪里读取记录。两个应用都可使用，并不意味着它们对每条记录都同时拥有决定权。

Microsoft 的 Strangler Fig 指南介绍了如何逐步迁移功能，并最终移除旧系统。整个过程中都需要处理依赖关系和共享数据。对企业负责人来说，关键是责任能否划分得足够清楚，以便每个阶段都能正常运作并得到核查。

刻意向两个系统写入数据。这种方式是通过软件设计，明确将变更记录到两个位置。由此也产生一项责任：当一次写入成功、另一次失败时该怎么办？必须有人发现差异、判定哪条记录具有权威性，并完成或更正缺失的工作。

Ed Murray 在 2020 年撰写的 AWS 迁移回退实践说明展示了双写和分阶段回退涉及的协调工作。这是有日期的技术案例，不是可以直接照搬的实施方案。手动重复录入，或承诺数据会自动同步，都没有厘清这些责任。

将并行运行与经过演练的单次切换比较

分阶段迁移可以限制每次变更涉及的工作范围，但维护两套运行环境会增加支持、培训、对账和临时集成工作。评估替换方案时，应把这些成本以及拆除临时连接的成本一并计算。

Ian Cartwright、Rob Horn 和 James Lewis 在 2022 年的文章 Transitional Architecture 中介绍了临时桥接方案及其最终拆除。他们的经验说明，桥接方案可以发挥实际作用，但仍需要单独的预算和退出安排。

如果系统规模较小、责任无法划分、缺少合适的集成点，或紧迫的退役期限不允许长期并行，那么经过演练的单次切换也值得纳入比较。Microsoft 指出了渐进式替换的类似适用限制。这些情况并不意味着单次切换天然安全，而是说明必须特别重视准备工作、运营检查和决策权限。

要求团队提供拟议转换方案的演练证据，并明确继续或停止的条件。按照必须持续开展的实际工作比较两种方案。任何一种安排都没有适用于所有情况的固定时长或验收门槛。

新交易会改变回退决策

员工在新系统中录入有效业务后，重新启用旧应用可能会让较新的记录留在新系统中。订单也可能已经触发配送、付款或消息发送，这些后续操作无法通过恢复数据库撤销。

AWS 的切换指南区分了尚未产生新数据时的回退，以及已产生新交易、原数据库可能已过时之后的回退。批准回退前，应要求团队具体说明如何处理新记录及其后续操作。仅有备份并不能证明业务可以连贯地恢复。

应要求的决策记录

一份简明记录应能帮助负责运营的人员回答以下问题：

• 目的与范围：要比较或迁移哪些工作？保留两个系统能达到什么目的？
• 权威记录：每个阶段在哪里录入变更？受影响的报表和业务操作以哪些记录为准？
• 对账：谁调查差异？如何记录？由谁处理有争议的结果？
• 验收：什么证据允许进入下一阶段？什么情况会停止进程？由谁作出继续或停止的决定？
• 回退：如果工作转回旧系统，如何处理新交易和已完成的后续操作？
• 退出：哪些证据表明可以退役旧系统？由谁移除临时桥接？根据适用要求，哪些记录必须继续可查？

当并行运行的目的和运营责任足以证明其成本合理，并且退出安排切实可行时，再予以批准。如果您正在评估系统替换，可以通过我们的 旧系统替换服务，讨论当前系统、必须持续开展的工作，以及变更时需要考虑的限制。