软件迁移怎么做？常见系统迁移类型与成功迁移方法

软件迁移是软件工程中最容易被忽视的话题之一，尤其是在高速发展的初创公司和大型企业中。

随着业务增长，公司往往需要采用新的系统和方法，以承载更高的负载、支持更多使用场景，或满足更多约束条件。于是，工程师有时就必须把旧系统或旧方法迁移到新系统或新方法上。这类系统迁移可能涉及服务替换、代码迁移、数据迁移、基础设施迁移等多种类型。

也正是在这个时候，事情开始变得有趣、出乎意料，甚至可能变得非常糟糕。

1. 四个不同的软件迁移案例

每一次迁移，本质上都是一个独立的故事。下面这四个软件迁移案例彼此差异很大，也分别代表了几种典型的迁移结果。

有计划停机的迁移

2012 年，某海外支付公司宣布，将在三小时的维护窗口内暂停全球支付处理系统一小时，以便迁移到新的基础设施。该公司认为，先关闭系统，将数据迁移到新基础设施，再重新启动，是当时最稳妥的方案。

尽管计划迁移时间安排在美国夜间，但由于该公司服务全球客户，迁移期间仍有部分交易无法处理，因此不可避免地造成了一定损失。不过，迁移最终按计划完成，业务中断和损失也都在该公司的预期范围之内。

一次彻底失败的系统迁移

某海外银行拥有约 500 万客户。2018 年，该银行进行了一次 IT 系统迁移，结果导致近 200 万客户无法登录账户，也无法正常取款。

这次迁移带来的问题花了数月才逐步修复。迁移事故发生五个月后，仍有部分客户无法登录账户。该银行首席执行官也因此被迫辞职，结束了长达七年的任期。

尽管事故的根本原因并未完全公开，但从事后报道来看，这场灾难似乎与迁移前测试不充分密切相关。媒体提到，配置问题、基础设施容量不足和代码缺陷，都是导致此次故障的可能原因。

这次系统故障至少给该银行造成了数亿美元损失，更不用说严重的声誉损害和业务冲击。

零停机迁移

2016 年，我加入某海外出行平台时，公司内部有两个支付系统：一个负责处理乘客相关付款，另一个负责处理合作伙伴相关付款。随后，我们开始构建一个全新的统一支付系统，用来替代这两个彼此独立的旧系统。

2017 年，我们将支付业务切换到了这个新的统一支付系统。

从外部看，这次切换几乎没有任何感知：迁移过程中没有停机，也没有出现重大问题。这是一次成功的零停机迁移。

然而，这次迁移的长尾持续了数年，而这条长尾后来也带来了一些问题。

迁移长尾导致的服务中断

尽管新的支付系统已经成为主系统，但该海外出行平台内部仍有数十个系统依赖旧支付基础设施。为了支持那些尚未迁移的系统，新系统需要将数据回写到旧系统中。

长期迁移往往伴随着风险，这一次也不例外。

2018 年，部分司机连续几天无法使用即时提现功能。原因是数据回写系统发生故障，而这个系统负责将生产数据推送到旧系统。由于处理司机付款的系统仍然依赖旧系统，回写数据无法到达，最终导致付款功能出现问题。

工程团队没能第一时间发现故障。原因在于，虽然生产支付系统拥有完善的监控能力，但回写系统原本只计划运行数月，却最终运行了数年，而它并没有配备足够完善的监控和告警机制。

迁移长尾非常常见，风险也很高，并且常常会引发服务中断。这个案例就是典型例子。

2. 常见的软件迁移类型

“迁移”这个词覆盖的范围很广。下面是工程师最常遇到的几类软件迁移类型。

服务替换迁移

服务替换，是指用新服务替换旧服务，并最终将所有客户、流量或业务逻辑迁移到新服务上。例如，上文提到的海外出行平台，就是用新的统一支付系统替换旧的传统支付系统。

这种迁移在任何快速发展的公司中都非常常见。团队之所以选择编写一个新服务，而不是继续改进旧服务，原因可能有很多，例如：

旧系统已经无法满足新的业务需求；

系统需要支持更高负载、更低延迟或更大数据规模；

旧服务所使用的语言、框架或技术栈，在组织内部已经不再被推荐或支持。

服务替换的难点在于，新服务通常并不是旧服务的简单复制。它往往伴随着新的架构、新的数据模型、新的接口，以及新的运行方式。因此，服务替换看似是“换一个系统”，实际上往往涉及业务逻辑、数据一致性、系统集成和运维能力的全面迁移。

服务集成迁移

服务集成，是指集成一项新的服务或新的调用方式。

例如：

• 接入一个新的 API，比如接入新的支付处理服务；
• 从外部服务的旧版本 API 迁移到新版本 API；
• 从轮询事件的方式，迁移到事件推送方式；
• 从同步消费事件，迁移到异步消费事件，并通过回调函数处理结果。

从这些例子可以看出，服务集成迁移包含很多不同情况。有些工程师甚至不会把其中某些工作视为“迁移”，而只是把它们看作普通功能变更。但我认为，这类变更也应该被视为迁移。

原因在于，这些变更都涉及外部服务行为的变化，而你的代码也必须随之调整，以保证未来行为仍然正确。正是这种外部依赖和行为变化，使这类改动具有风险。因此，更明智的做法是把它们当作迁移来处理，并遵循相应的迁移原则。

服务拆分迁移

服务拆分，是指将系统内部依赖拆分出来，转变为系统外部依赖。这是高增长型初创公司中非常常见的一类迁移，通常用于将大型服务拆分成多个更小、更独立的服务。

从表面看，服务拆分似乎是最简单的迁移之一。毕竟，我们只是把已经能正常运行的代码搬到一个新服务里，对吗？

错。

服务拆分的风险远不止“移动代码”这么简单。它不仅引入了网络通信问题，还会影响新服务的正确性。尤其是在现实情况中，代码很少能够被原封不动地复制粘贴过去。此外，服务拆分还会带来未来运维层面的风险，例如监控、告警、扩缩容、发布流程和故障排查方式都可能发生变化。

虽然服务拆分是相对容易“看起来完成”的迁移类型之一，甚至有时不做完善监控和告警也能上线，但我建议不要被这种表面简单性诱惑。更稳妥的方式，是遵循一套完整的迁移运行手册。

代码迁移

代码迁移，是指将代码库的一部分迁移到不同的框架、库或编程语言上。

这类迁移面临的最大挑战包括：

第一，变更规模大。它通常需要修改大量文件和代码行。

第二，回滚困难。由于变更范围很大，因此很难轻松回滚，有时甚至几乎不可能回滚。这与大多数代码变更截然不同，因为普通代码变更多数范围较小，可以比较容易地撤销。

第三，生产环境测试更困难。由于改动范围很广，很难在真实生产流量下全面验证所有行为。

常见的代码迁移示例包括：

迁移到新的编程语言。例如，某海外支付基础设施公司曾在一个周末内，将数百万行使用某类型检查工具的 JavaScript 代码迁移到了 TypeScript；

升级到某个库的主版本，而新版本引入了破坏性 API 变更；

改变整个代码库的编码模式。例如，将 JavaScript 代码库从使用回调函数，更新为使用 Promise。

代码迁移通常容易被低估。它看起来只是“改代码”，但由于变更面广、影响范围大、回滚困难，因此需要非常谨慎的计划和验证。

数据迁移

数据迁移，是指将一个或多个数据库迁移到新的数据模式或新的数据库引擎上。

数据迁移是风险最高的迁移类型之一，主要原因有以下几点。

第一，回滚困难。代码变更可以通过回滚代码来撤销，但数据变更并不总是如此。一旦数据被转换、覆盖或写入新结构，恢复旧状态可能非常复杂。

第二，数据迁移很难以原子方式完成。理想情况下，数据迁移应该像一次原子操作：从某一刻开始，旧数据库或旧模式停止使用，所有数据都已经迁移到新数据库或新模式。但在现实中，数据迁移通常需要时间。也正因为如此，停机迁移在数据迁移场景中往往更容易实施。

第三，数据迁移通常与代码变更紧密相关。为了确保迁移按预期进行，团队往往需要在迁移数据的同时调整代码逻辑。

第四，需要考虑更多边界情况。例如，生产者是否仍会写入旧数据库？消费者是否能够理解新模式？旧数据和新数据是否会同时存在？这些特殊情况都必须提前考虑。

数据迁移的复杂性，往往不是来自“把数据搬过去”本身，而是来自迁移过程中新旧系统并存、读写路径变化和数据一致性保障。

基础设施迁移

基础设施迁移，是指将存储、计算或网络基础设施迁移到新的供应商、新的位置或新的架构上。

基础设施迁移风险极高，因为它会影响所有依赖该基础设施的服务。一旦基础设施迁移出现问题，可能导致所有相关服务同时受影响。因此，基础设施迁移通常比数据迁移还需要更充分的准备。

与其他迁移类型相比，代码迁移和数据迁移通常属于虚拟层面的迁移，而基础设施迁移可能涉及物理基础设施的移动或变更，也可能需要现场操作。

虽然如今大多数公司都会使用主流云服务商，但仍有不少公司运营自己的数据中心或服务器。基础设施迁移可能意味着对这些数据中心、服务器、网络或存储设施进行调整。

此外，服务和工具升级也可能导致服务中断。例如，升级 CI/CD 系统、升级研发协作工具，或进行其他工具基础设施变更，都可能引发中断风险。

对于这类升级，迁移工作通常由工具供应商承担。但工程团队仍然应该了解迁移过程的底层机制，判断是否存在高风险升级，并采用类似本文讨论的方法来降低风险。

3. 为什么系统迁移值得被认真对待

迁移之所以容易被低估，是因为它常常不像新功能那样令人兴奋。它不会直接带来新的用户界面，也不一定能立即提升核心业务指标。很多时候，它只是为了让系统能够继续支撑业务增长，或者避免未来发生更严重的问题。

但迁移失败的代价往往极高。它可能造成服务中断、客户无法使用产品、数据不一致、收入损失，甚至引发严重的声誉危机。

成功的迁移通常看起来“什么都没发生”。用户没有感知，业务没有中断，系统平稳切换，一切照常运行。也正因为如此，优秀的迁移往往不容易被看见。

但这并不意味着迁移不重要。恰恰相反，软件迁移是复杂软件系统能够持续演进的关键能力。

4. 如何做好软件迁移

本文是关于“如何做好迁移”的系列文章第一部分，重点介绍了迁移的典型案例和常见类型。

后续内容通常还需要继续讨论以下问题：

迁移前应该如何准备；

迁移期间应该如何执行；

迁移完成后应该如何验证；

如何处理迁移长尾；

如何向业务方解释迁移价值；

如何处理迁移过程中的组织和人员问题。

迁移并不是一次简单的技术操作，而是一项需要工程能力、产品判断、风险管理和组织协作共同参与的系统性工作。

在实际落地中，团队可以借助 PingCode 这类智能化研发管理工具，将团队目标、需求评审、开发任务、测试验证、发布上线和 Wiki 知识沉淀串联起来，并打通研发过程中使用的其他工具，让迁移过程中的计划、风险、进度、验证结果和经验复盘能够被持续记录和追踪。

对于工程团队来说，真正重要的不是“是否要迁移”，而是如何以可控、可验证、可回滚、可沟通的方式完成迁移。优秀的软件迁移，往往不是靠一次大胆切换完成的，而是靠充分准备、渐进执行、持续监控和清晰沟通一步步完成的。