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