在旧系统迁移之初，时间表总是看起来很合理。旧系统是为人所理解的，至少对构建它的人来说是这样。新系统已设计完毕。范围已界定。六个月是一个乐观的估计，但并非荒谬可笑。十二个月算是保守估计。如果向领导层承认需要十八个月，那会显得很难堪。
三年后，迁移要么仍在进行，要么已被悄悄取消，要么在完成时做出了太多妥协，以至于一些最初的问题又直接在新的代码库中重现。这并非罕见的结果。这是最常见的情况。
大多数团队给出的解释都是技术层面的：旧系统比预期的要复杂，新平台有出乎意料的限制，数据模型无法完美映射。这些情况确有其事，也确实影响了项目进度。但它们并不是迁移需要三年时间的根本原因。真正的原因几乎完全是组织层面的。
你要替换的系统永远无法被彻底理解
旧系统积累业务逻辑的方式，就像老建筑积累承重墙一样。2009年为了处理一个边缘情况而添加了某些东西。2013年为了应对某个客户异常而打了个补丁。2017年对某项计算进行了微调，因为有人注意到数字不对，但没人能完全说清楚具体是怎么不对。做出每一次修改的人可能已经离开了公司。系统之所以以现在这种方式运行的原因，通常并没有被记录在任何地方。
迁移的调研阶段——即弄清楚旧系统实际功能的阶段——几乎总是被低估了工作量。团队在开始设计前花了两个星期进行调研，没有发现明显的意外情况，于是得出结论：系统已被充分理解。然后，他们在接下来的十八个月里不断发现各种“意外惊喜”。
一个更诚实的做法是，假设旧系统包含的未记录业务逻辑大约是目前所有人认为的三倍，并据此来规划调研工作。在实践中，这意味着让新旧系统并行运行的时间要比让人觉得舒服的时间长得多，要接受有些边缘情况只有在真实用户在生产环境中遇到时才会浮现，并将旧系统的实际行为视为规范，而不是去看需求文档。
了解旧系统的人永远无法全职投入
旧系统迁移的领域专家——那些了解系统为何具有某种行为的人——几乎总是那些负责日常业务运营的人。如果不影响为项目提供资金的业务运营，他们就无法全职借调到迁移项目中。
通常发生的情况是一种妥协：领域专家参加研讨会，根据需要回答问题，并在有时间时审查交付物。在早期阶段，当问题都具有战略性时，这种方式效果还不错。但在实施阶段，当问题变得具体时，它就成了一个瓶颈：当这个字段为空时应该发生什么？这个行为是故意的还是一个漏洞？这个状态码在这个特定工作流的上下文中意味着什么？
这些问题并不难。每个问题只需要十分钟就能解答。但这类问题有成千上万个，它们不可预测地出现，如果合适的人不在场，每一个问题都可能阻碍一个冲刺阶段（sprint）。迁移过程在不知不觉中累积了等待时间，这些时间从未作为单一的阻碍项出现在状态报告上，但加起来却占据了几个月的实际日历时间。
利益相关者的共识被消磨
赞助此次迁移的高管有着明确的理由：降低运营成本，消除技术债务，实现旧系统无法支持的功能。这个理由足够有说服力，从而争取到了预算和时间表。项目进行了十八个月后，这位高管调到了其他岗位。他们的继任者接手了项目，却没有继承当初推动这个项目的坚定信念。
这并不是个人的失败。这是由迁移所需的时间与组织变革的频率相对比而产生的一种结构性特征。一个为期三年的项目，平均而言，会比委派该项目的高管的任期还要长。一旦发生这种情况，项目就会在最需要组织支持的时刻失去它的保护人——在这个艰难的中间阶段，旧系统仍在运行，新系统尚未准备就绪，而团队正在申请更多的时间和资金来弥合这一差距。
那些能在这个过渡期幸存下来的迁移项目，通常拥有分布式的赞助——在足够多的层级上有足够多的人理解该项目存在的原因，因此它能够承受任何单一倡导者的离职。这比寻找一位单一的高管赞助人更难建立，而且很少自然形成。它必须被刻意培养，通常需要向核心项目团队以外的更广泛的受众进行定期沟通。
百分之八十完成度是一个陷阱
迁移过程中最危险的里程碑就是“百分之八十完成”。在那一点上，新系统处理了所有的常见情况。主要工作流都能正常运行。可以进行像样的演示。剩下那百分之二十是一长串为了保持主流程推进而被推迟的边缘情况、异常情况和不寻常场景的清单。
那百分之二十代表了多年生产使用中所积累的复杂性。列表上的每一项之所以存在，是因为有真实用户遇到了标准工作流无法处理的真实情况。总而言之，它们编码了关于业务“实际如何运作”而不是“应该如何运作”的大部分机构知识。
处理它们的速度很慢，因为每一项都需要经历相同的周期：理解原始场景，设计处理方法，实施它，并与了解该领域的人进行验证。这里没有规模经济可言。处理第一百个边缘情况并不会比处理第一个更快。而且这个列表并不会稳步缩小——随着新系统被更广泛地使用并暴露出以前不为人知的场景，它往往会不断增加。
按计划达到百分之八十完成度的团队常常会发现，剩下的百分之二十所需的时间和前百分之八十一样长。这并不是计划的失败。这是这些系统的复杂性所在的一种数学属性。
那些最终完成的迁移项目有什么共同点
那些真正完成的旧系统迁移项目拥有一些在开始时不那么明显的共同特征。
它们将切换过程视为一个需要被设计的事件，而不是一个要跨越的门槛。旧系统被关闭，新系统成为记录系统的那一刻，是整个项目中风险最高的时刻。那些为这一事件制定明确计划的组织——谁可以进行回滚，在什么条件下回滚，谁来拍板，怎样才算是一个成功的首周——更有可能顺利渡过这一阶段，而不会发生导致时间表再倒退六个月的危机。
它们让新旧系统并行运行的时间比原计划更长。这既昂贵又会在操作上令人感到不适。但它也能暴露出自动化测试无法捕捉到的边缘情况，从而避免它们在一个不再有退路的系统中演变成生产事故。
它们规划的迁移范围是渐进式地交付价值，而不是在一次切换中全部完成。最糟糕的迁移是那种在所有东西都完成之前没有任何东西可以退役的迁移。最优秀的迁移项目能够识别出旧系统中哪些部分可以独立退役，并对工作进行排序，在项目满三年之前就能交付可见的成果。
而且他们很早就对实际的时间表坦诚相待。这并非是为了刻意压低预期，而是因为一个知道项目需要三年的组织可以调整其自身结构来维持它。如果一个组织认为项目只需要六个月，并且反复被告知项目快完成了，那么它失去耐心的速度将会快到项目无法存活。