依赖服务前，先验证退出方案

定义哪些内容必须继续可用

源代码所有权很有价值，但它只是退出计划的一部分。

考虑一个虚构应用：源代码位于公司代码仓库中，构建时需要从供应商下载私有软件包。生产环境使用供应商拥有的云账户，而数据库恢复流程无人记录。

公司拥有代码，却还不能独立运行服务。退出计划必须同时覆盖权利、资产、访问和知识。

清点依赖

检查导出格式与范围。可读的文档导出，不一定保留每个关系、附件或执行记录。索取样本，并与未来使用这些内容的人一起检查。

独立重建一次

使用安全的测试环境和获准示例数据。将拟交接的材料交给获授权工程师。要求其构建应用、应用配置、恢复数据，并验证一项完整业务操作。

记录每项缺失内容及取得它所需的时间。演练中，不要悄悄补充未写入文档的知识。目的是找出接手团队会缺少什么。

随后检查过渡限制：订阅重叠期、数据传输时间、软件包访问、身份变更和可用支持。将这些成本纳入自建与采购比较。

区分导出与删除

导出会生成副本。过渡会改变服务运行方。删除会按约定流程移除指定记录。这是三种独立决定，需要不同证据。

与相关负责人确定保留要求和删除范围。确认供应商当前的条款与流程。接收系统通过验证前，不要删除唯一可用的恢复副本。

Taiga 文档说明了管理导出流程，以及独立的数据擦除流程。导出不包含秘密信息的值。因此，交接必须包含一种获授权的方式，用于重新创建所需秘密信息。根据过渡需求验证当前导出内容，不要假设它是完整应用备份。

决定哪些依赖可以接受

可移植性不要求移除所有托管服务。如果理解其价值、限制和过渡路径，保留依赖可以是合理选择。

记录接受的依赖、负责人和复核触发条件。架构或合同发生重大变化后，再次执行退出演练。继续制定采用计划，从一开始就纳入这些职责。