规划迁移波次

本文档介绍了如何规划迁移波次。

您可以将候选迁移分组到不同的迁移波次中。根据您在发现和评估阶段收集的信息,您可以在概要级别(基于类别)或详细级别(应用、位置、组件)分组。

创建应用目录

如需开始规划,请创建应用目录。根据应用架构、业务注意事项和 IT 运营,对您的应用进行分类。这有助于根据迁移到云端的业务重要性、复杂性和风险来确定它们的优先级。这些因素的组合和优先顺序因组织、其业务需求以及它们与工作负载的对应关系而异,无论是在当前架构和未来的 Google Cloud 架构中。

以下列表介绍了三个主要类别,以及每个类别中您需要考虑的因素。

  • 应用架构

    • 技术限制
    • 依赖项数量
    • 层级数
    • 有状态与无状态
    • 性能要求
    • 地理位置依赖项
  • 业务注意事项

    • 合规要求
    • 业务重要性
    • 业务变更能力
    • 用户数量
    • 用户类型(内部、外部)
    • 总拥有成本
  • IT 运维

    • 操作环境
    • 服务等级协议
    • 可用情况
    • 备份

要考虑的应用目录维度。

绘制地图并确定优先级

从应用目录中,根据复杂性和目标迁移方法映射应用。迁移方法应基于您在迁移期间和迁移之后的预期业务结果、迁移工作以及相关风险因素。

然后,根据业务价值和迁移所需的工作量,按优先级顺序对候选迁移进行排名。为了做好迁移准备,请首先确定其功能可能会使应用被迁移的应用。您可以选择只使用一个,也可以在第一波测试中添加多个应用。第一波中的应用让您的团队可以在云环境中测试部署,同时专注于迁移而不是应用的复杂性。

从独立应用入手可以降低您的初始风险,因为稍后您可以将团队的新知识应用于更复杂且具有许多依赖项的应用。

第一波浪潮中的应用通常不是业务关键型应用,并且具有较少的系统和网络到网络依赖项。它们所需的重构也更少,数据重心通常较小,没有特定的合规性挑战,并且能够承受割接期。如需了解详情,请参阅如何选择要先迁移的应用

按复杂性绘制应用地图。

按 wave 对应用程序进行分组

将应用划分为多个波次,每个波次有关联的时间轴,以及根据每个波次反馈修改计划的时间。

  • 第 1 波:商业价值高,实现容易。
    • 这些应用是早期迁移或概念验证的理想选择。
  • 第 2 波:高商业价值,大量实现工作。
    • 这些应用可能会优先处理。
  • 第 3 波:业务价值低,实现起来不容易。
    • 这些应用可能会优先处理。
  • 第 4 波:低商业价值,大量实现工作。
    • 这些应用应该放在最后。

正在规划迁移波次。

定义迁移波次后,您可以在项目计划中将其整理。

迁移时间表和项目计划。

遵循最佳实践

如需改进迁移计划,请按照验证迁移计划的最佳实践进行操作。即使遵循该文档中的概念,我们并不能保证您一定能成功。 但是,本文档重点介绍了在规划迁移时经常被忽略的一些要点,例如:

  1. 确保在迁移计划的每个步骤上都有回滚策略。
  2. 如本文档前面所述,规划逐步发布和部署。
  3. 提醒负责工作负载迁移的所有开发和运营团队。
  4. 从目标生产环境中移除概念验证资源和实验。
  5. 定义安全停用来源环境的条件。
  6. 确保针对每个迁移波次进行迁移风险评估,并针对发现的风险执行缓解措施。

后续步骤