本文档介绍了如何规划迁移波次。
您可以将迁移候选对象分组到迁移波中。您可以根据在发现和评估阶段收集的信息，从高级别（基于类别）或详细级别（应用、位置、组件）进行分组。
创建应用目录
若要开始规划，请创建应用目录。根据应用架构、业务考虑因素和 IT 运营情况，将应用整理到各个类别中。这有助于根据业务关键性、复杂性和迁移到云端所涉及的风险来确定其优先级。 这些因素的组合和优先级因组织、业务需求以及这些需求与工作负载的映射（无论是在当前架构中还是在未来的Google Cloud 架构中）而异。
下表列出了三个主要类别，以及您需要在每个类别中考虑的因素。
应用架构
- 技术限制
- 依赖项数量
- 层级数
- 有状态与无状态
- 性能要求
- 地理位置依赖关系
业务考虑因素
- 合规要求
- 业务关键程度
- 商家变更功能
- 用户数量
- 用户类型（内部、外部）
- 总拥有成本
IT 运营
- 运营环境
- 服务等级协议
- 可用性
- 备份
映射和确定优先顺序
根据复杂程度和目标迁移方法，从应用目录中规划应用。 迁移方法应基于您预期的业务成果、迁移工作量以及迁移期间和迁移后的相关风险因素。
然后，根据业务价值和迁移所需的工作量，按优先级对迁移候选对象进行排名。为了做好迁移准备，您需要确定具备可能使其成为“先驱”的特性的应用。您可以选择一个，也可以在第一波中包含多个应用。 通过第一批迁移的应用，您的团队可以在云环境中测试部署，同时专注于迁移而不是应用的复杂性。
首先处理独立应用可降低您的初始风险，因为稍后您可以运用团队学到的新知识来处理更复杂且具有许多依赖项的应用。
第一波迁移的应用通常不是业务关键型应用，并且系统和网络间依赖关系较少。它们还需要较少的重构，通常具有较小的数据引力，没有特定的合规性挑战，并且可以承受割接窗口。如需了解详情，请参阅如何选择要先迁移的应用。
按波次对申请进行分组
将申请分组为多个批次，并为每个批次关联时间表，以及根据每个批次中的反馈修订方案的时间。
- 第 1 波：业务价值高，实施起来毫不费力。
- 这些应用非常适合早期迁移或概念验证。
- 第 2 轮：业务价值高，但实现难度大。
- 这些申请可能会优先处理。
- 第 3 波：业务价值低，实施难度低。
- 这些申请可能会优先处理。
- 第 4 波：业务价值低，实现难度大。
- 这些应用应最后优先考虑。
定义迁移波次后，您可以在项目计划中整理这些波次。
遵循最佳实践
如需改进迁移计划，请遵循验证迁移计划的最佳实践。 遵循该文档中的概念并不能保证一定成功。 不过，该文档重点介绍了一些在规划迁移时经常被忽略的方面，例如：
- 确保您为迁移计划的每个步骤制定了回滚策略。
- 规划逐步发布和部署，如本文档前面部分所述。
- 提醒负责迁移工作负载的所有开发和运营团队。
- 从目标生产环境中移除概念验证资源和实验。
- 定义安全停用来源环境的标准。
- 确保您针对每个迁移波次执行迁移风险评估，并针对已识别的风险执行缓解措施。
后续步骤
- 了解如何执行迁移。