遗留系统承载的不只是旧代码
成熟的系统通常包含多年协商的业务行为。有些规则在代码中是明确的。其他存在于批次计时、数据库约定、操作清单、供应商程序和有经验的人员的判断中。从技术角度来看，这些元素可能看起来是偶然的，但对于连续性仍然至关重要。
当当前系统仅记录为要替换的组件时，现代化就会失败。更有用的视图映射了它支持的功能、它支持的决策、它拥有的关键数据、它提供的下游依赖项、它提供的控制以及人们围绕它管理的异常。该视图揭示了哪些内容可以更改以及哪些内容必须保持连接。
先建立连续性清单，再建立替换待办
连续性登记册规定每次转换必须保留的事实和行为：稳定的身份、业务定义、批准权限、计时义务、协调规则、审计证据、恢复期望和服务边界。每个项目都应该有一个所有者和测试它的方法。登记册并不是再现所有历史行为的借口；它是有意决定保留、更改或淘汰哪些内容的基础。
这改变了发现。团队不只是询问用户需要什么功能，而是询问规则为何存在、规则发生变化会产生什么后果以及谁有权接受该后果。当过时的行为的目的和依赖性经过检查后，就可以放心地删除它。重要的行为可以重新设计，而不是意外丢失。
同时设计目标架构与过渡架构
目标架构显示预期的未来职责和边界。它本身并不表明组织明天如何运作。转换架构描述了数据、接口和用户移动时必须承载实际工作的中间状态。它们包括临时所有权、共存、协调、额外控制和明确的退休标准。
与目标一起设计转换可以测试目标是否可以实现。如果没有可靠的方法来移动关键身份、同时运行新旧规则或验证两个领域的结果，则目标可能需要不同的边界。过渡本身就是一个架构，而不是可以保持未记录的项目脚手架。
按业务能力与验证证据切分迁移
技术层很少是最安全的迁移单元。首先移动所有数据，然后是所有服务，最后是所有渠道，可能会造成很长一段时间不拥有完整的业务成果。能力切片遵循一条通过规则、数据、接口和操作的有意义的路径。可能比较狭隘，但是整体上还是可以接受的。
根据依赖性和结果选择切片，而不仅仅是轻松。早期工作应该测试最危险的假设，同时避免不可接受的爆炸半径。每个切片都需要成功、协调和恢复标准。完成意味着组织可以操作和解释新路径，而不仅仅是已部署的代码。
把共存阶段作为运营模式来设计
并行操作引入了迁移图经常忽略的问题。每个事实哪个系统具有权威性？双方都能接受改变吗？身份如何关联？当结果不同时，谁来决定？和解必须多快发生？有什么证据证明新行为在等效性很重要的情况下是等效的？
这些是运营决策。他们需要所有者、操作手册、监控和升级。双写入或数据复制可以是该机制的一部分，但两者都不能建立业务权限。清晰的事实来源决策和受控异常路径比同步技术的复杂性更为重要。
恢复必须覆盖业务状态，而不只是部署版本
回滚应用程序版本不会自动撤消活动期间接受的订单、发送的通知、记录的决策或转换的数据。恢复计划必须确定不可逆转的影响、补偿措施以及不再负责返回到先前状态的点。
对于每个转换，定义可以重试、重播、协调、补偿或恢复的内容。测试决策过程和机制。领导者应该知道谁可以暂停进程、哪些证据会触发该选择，以及在了解问题后如何继续操作。
以决策阈值治理路线图，而不只依赖日历
现代化路线图应显示在状态之间移动所需的证据：理解规则覆盖范围、在批准的容差范围内进行数据协调、进行恢复测试、接受支持所有权或删除关键依赖项。日期很重要，但没有阈值的日期鼓励在风险发生变化之前报告进展情况。
决策记录保存选择目标、序列或临时妥协的原因。他们还指出何时应该审查假设。这使得治理变得更轻松、更有用：它将注意力集中在随之而来的不确定性上，而不是要求每个细节都通过同一个论坛。