规划迁移波次

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

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

您可以将迁移候选对象划分为迁移波次。根据您在发现和评估阶段收集的信息,可以在高级(基于类别)或详细级(应用、位置、组件)下进行分组。

创建应用目录

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

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

  • 应用架构

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

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

    • 运营环境
    • 服务等级协议
    • 可用情况
    • 备份

为应用目录考虑的维度。

绘制地图并确定优先级

从应用目录中,根据复杂性和目标迁移方法规划应用。在迁移过程中和迁移之后,您的迁移方法应基于您预期的业务成果、迁移工作和相关的风险因素。

然后,根据业务价值和迁移所需精力,按优先级对迁移候选对象进行排名。为做好迁移准备,请找出具有以下特点的应用:可能先迁移应用。您可以只选择一个,也可以在第一个波次中添加多个应用。第一波中的应用可让您的团队在云环境中测试部署,同时专注于迁移而不是应用的复杂性。

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

第一波中的应用通常不是业务关键型应用,并且系统和网络之间的依赖关系较少。它们还需要进行较少的重构,通常数据重力较少,没有特定的合规挑战,并且能够实现割接期。如需了解详情,请参阅如何选择要迁移的应用

按复杂性绘制应用。

分波式处理应用

使用与每个波次关联的时间轴将应用分组到多个波次中,并利用每个波次的反馈修改计划。

  • 第 1 轮:商业价值高,实现所需付出少。
    • 这些应用非常适合用于早期迁移或概念验证。
  • 第 2 轮:具有较高的业务价值,需要付出很多努力才能实现。
    • 接下来可能会优先考虑这些应用。
  • 第 3 轮:业务价值低、实现所需投入少。
    • 接下来可能会优先考虑这些应用。
  • 第 4 轮:业务价值低、实现付出很大。
    • 这类应用应排在最后。

规划迁移波次。

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

迁移时间表和项目计划。

遵循最佳做法

如需改进迁移计划,请遵循验证迁移计划的最佳做法。遵循该文档中的概念并不能保证一定有效。 不过,本文档重点介绍了规划迁移时经常被忽视的一些要点,例如:

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

后续步骤