我参与过的最有趣的迁移是 Uber 从 Puppet 管理的服务迁移到完全自助式的供应模式，在这种模式下，公司的任何工程师都可以通过两次点击启动一项新服务。他们不仅可以，而且还做到了，在服务完成时，每天都能提供多个服务，每个新聘用的工程师在第一天都能从头开始启动一项服务。
这次迁移之所以如此有趣，是因为迁移量非常大。刚开始时，调配一项新服务大约需要两周的时间和两天的工程时间，而且我们每天都在落后。当时的压力可不仅仅是一点点，但这也是一个学习如何进行大规模软件迁移的完美实验室：它足够大，甚至可以看到微小的变化；它足够长，我们可以尝试多种方法。
随着代码库的老化和业务的增长，迁移既是必要的，也是令人沮丧的：大多数工具和流程只能支持一个数量级的增长，然后就会失效，因此快速增长使迁移成为一种生活方式。这并不是因为它们是糟糕的流程或差劲的工具，恰恰相反：在规模显著扩大时停止工作这一事实表明，它是根据以前的限制条件适当设计的，而不是设计过度。
因此，你会经常更换工具，而你迁移到新软件的能力很容易成为你整体速度的决定性制约因素。鉴于迁移的重要性，我们并不经常谈论运行迁移；让我们来弥补这一点！
迁移为何重要
迁移之所以重要，是因为迁移通常是在技术债务方面取得有意义进展的唯一途径。
工程师讨厌技术债务。如果有一个简单的项目可以让他们亲自动手来减少技术债务，他们就会自己去做。工程经理也讨厌技术债务。如果他们的团队可以单独执行一个简单的项目，他们就会安排这个项目。总而言之，这就导致了一种动态情况，即几乎没有什么低垂的果实可以减少技术债务，而剩下的大多数选择都需要许多团队合作才能实现：迁移。
每种迁移的目的都是创造技术优势（"你的索引不再需要放在一台服务器上了！"）或减少技术债务（"你的确认写入可以保证在主站故障转移时持续存在"）。它们占据了一个尴尬的领域，即通过减少当前的贡献来换取明天更多的容量。这使得它们在调度上存在争议，而且随着系统规模的扩大，它们的成本也会越来越高。
传说 Googlers 有一句话叫 "Running to stand still"，用来形容一个团队的全部能力都耗费在升级依赖关系和模式上，以至于无法在自己的产品/系统上取得进展。把所有时间都花在迁移上是极端的做法，但每家中型公司都有一长串无法完成的迁移任务：从虚拟机迁移到容器、推出断路器、迁移到新的构建工具；这些任务不费吹灰之力就能排到日落时分。
随着公司和代码的发展，迁移是有效管理技术债务的唯一机制。如果不能有效地进行软件和系统迁移，最终就会陷入技术债务的泥潭。(不管怎样，以后还是要做迁移，只不过可能是全面重写）。
做好迁移工作
好消息是，虽然迁移很难，但有一套相当标准的流程可以很好地运行：清除风险、启用，然后完成。
1、消除风险
迁移的第一阶段是消除风险，而且要尽可能快速、低成本地完成。编写一份设计文档，并与你认为最难完成迁移的团队进行讨论。迭代。与具有非典型模式和边缘案例的团队讨论。迭代。根据未来六到十二个月的路线图进行测试。迭代。
设计进化完成后，下一步就是嵌入最具挑战性的一两个团队，与这些团队并肩工作，构建、进化并迁移到新系统。不要从最简单的迁移开始，这会导致错误的安全感。
有效地降低风险是至关重要的，因为每个支持迁移的团队都在向你打赌，你一定会完成这个该死的任务，而不会让他们迁移到一个废弃的系统，不得不重新恢复。如果你只完成了部分迁移工作，人们就会对参与下一次迁移产生极大的怀疑。
2、启用
一旦验证解决方案能够解决预期问题，就该开始打磨工具了。很多人在开始迁移时都会生成跟踪票据，让团队去实施，但最好还是放慢脚步，建立工具，以编程方式迁移 90% 的简单内容。这将从根本上降低整个组织的迁移成本，从而提高迁移的成功率，并为未来的迁移创造更多机会。
一旦你已经尽可能多地以编程方式处理了迁移工作，你就应该找出可以提供的自助服务工具和文档，让员工能够在不陷入困境的情况下进行必要的更改。最好的迁移工具是渐进和可逆的：如果出现问题，用户应该能够立即返回到以前的行为，并具有必要的表达能力，以消除其特定迁移路径的风险。
文档和自助服务工具都是产品，在同样的制度下也能茁壮成长：与一些团队坐下来，看着他们按照你的指示去做，然后加以改进。再找一个团队，重复进行。多花两天时间有意识地使文档简洁、工具直观，可以为大型迁移节省数年时间。就这么做
3、完成
迁移的最后一个阶段是淘汰被取代的旧系统。这需要达到 100% 的采用率，而这可能是相当具有挑战性的。
首先要止血，即确保所有新编写的代码都使用新方法。这可以是在衬垫中安装棘轮，也可以是更新文档和自助工具。这始终是第一步，因为它会把时间变成你的朋友。你现在不是在默认情况下落后，而是在默认情况下取得进步。
好了，现在你应该开始生成跟踪票据，并建立一种机制，将迁移状态推送给需要迁移的团队和一般管理结构。让更广泛的管理层了解迁移情况非常重要，因为他们需要优先考虑迁移工作；如果某个团队没有开展迁移工作，通常是因为他们的领导层没有将其列为优先事项。
在这一点上，你已经非常接近于完成，但还有很长的一段路要走。你现在的工具就是自己完成。这不一定很有趣，但要实现 100% 迁移，需要领导迁移的团队自己深入到各个角落。
完成迁移的最后一个建议是表彰。在迁移过程中庆祝迁移是很重要的，但大部分庆祝和表彰都应留给迁移的成功完成。特别是，开始迁移但没有完成迁移往往会产生大量的技术债务，因此你的激励和表彰结构应注意避免不正当的激励。