规划迁移

迁移计划定义了将工作负荷迁移到 Azure 的特定顺序、时间和方法。 此计划将高级迁移策略转换为可作的部署序列。 它基于云采用计划，通过解决工作负荷优先级、迁移排序和数据传输方法等战术决策。

先决条件：迁移采纳计划、Azure 登陆区

评估迁移准备情况和技能

就绪情况评估可确保你的团队具备执行迁移计划所需的技能和支持。 此步骤确定功能差距，并通过有针对性的训练或外部支持加快进度。

1. 评估团队的 Azure 技能。 查看团队对 Azure 服务、迁移工具和直接转换的体验。 此评估可帮助你识别特定的知识差距，并确定团队需要哪些培训才能成功。

2. 根据需要利用外部专业知识。 如果团队缺乏云迁移经验，请引进 Microsoft或Microsoft合作伙伴。 外部专家可以验证迁移策略，建议适当的工具，并帮助建立现实的时间线。 此支持可降低风险并加快迁移速度，尤其是对于复杂项目或大型项目。

选择数据迁移路径

数据迁移路径是将数据从当前位置移动到 Azure 的方式。 正确的路径可确保数据传输安全、快速且经济高效。 首先，检查可用的网络连接、ExpressRoute、VPN 或公共 Internet，以了解选项。

1. 拥有 ExpressRoute 时，请使用它。 ExpressRoute 提供与 Azure 的专用连接，比 Internet 连接更快、更安全。 如果已有 ExpressRoute 或计划获取它，请对所有工作负荷使用此方法。 请记住，ExpressRoute 需要设置时间并具有数据传输成本。

2. 如果 ExpressRoute 不可用，请使用 VPN。 如果需要安全数据传输，但没有 ExpressRoute，请选择 VPN。 VPN 通过 Internet 创建到 Azure 的加密隧道，但通常比 ExpressRoute 慢。 在开始之前，请确保已在 Azure 中配置 VPN 网关。

3. 使用 Azure Data Box 来处理大量数据。 Data Box 最适合使用大量数据进行脱机迁移。 Microsoft会将一个实体设备寄送给您，让您可以将数据复制到设备上，然后您寄回设备。 此选项可避免使用网络，但由于整个运输过程花费时间最长，所以需要最长时间。

4. 可以将公共互联网用于处理不太敏感的数据。 此选项适用于数据不需要加密且无法使用 ExpressRoute 或 Data Box。 虽然此方法随处可用，但它是最不安全的，可以减缓其他 Internet 活动的速度。

确定迁移顺序

迁移排序通过建立工作负荷迁移的逻辑顺序来降低风险并建立团队信心。 该序列确定哪些工作负载首先移动，以及依赖组件如何一起迁移，以防止服务中断。 将大型投资组合划分为迁移波。 有关波形规划的详细指南，请参阅 迁移波规划。

查找依赖项

1. 首先发现所有依赖项。 工作负荷之间的依赖关系会导致服务中断（如果未一起迁移）。 映射内部和外部依赖项 ，以在创建迁移组之前发现这些连接。

2. 分析依赖项类型和关键性。 不同的依赖项类型需要不同的迁移方法。 区分以下类别：

   依赖项类型	Description	迁移方法
   直接依赖项	需要即时通信和组件之间的低延迟。	将所有直接连接的组件一起移动，以保持性能并避免中断。
   间接依赖项	涉及系统之间的偶尔或非关键交互。	在连接允许延迟或支持混合使用的情况下，可以一起或分批迁移。
   业务依赖项	取决于组织或管理关系。	将相关的工作负载和报告系统组合在一起，以符合业务优先级。

3. 按依赖项关系对工作负荷进行分组。 基于共享数据库、API、身份验证服务或网络连接创建组。 这些组构成了迁移波的基础，并确保需要的所有组件一起移动以保持功能正常运行。 当依赖项严重性存在不确定性时，将组件组合在一起。 这种保守的方法为将来的分离提供了灵活性。

4. 系统地记录每个依赖项组。 依据依赖项组使用一致的命名约定标记资产。 记录每个组，其中包含：

   • 组名称和 ID - 唯一标识符和描述性名称
   • 组件清单 - 所有基础结构元素、应用程序和服务
   • 关键依赖项 - 需要特殊处理的基本连接
   • 迁移约束 - 业务、技术或计时要求

5. 验证组完整性。 确认每个组包括应用程序运行所需的所有组件，包括支持基础结构，例如负载均衡器、DNS 记录或缓存层。

处理拆分环境操作

1. 为不可移动的依赖项制定计划。 确定因技术或法规原因而必须保留在源环境中的组件。 记录他们无法移动的原因、连接到其他系统的方式以及共享的数据。 本文档可帮助你为这些组件创建策略，以顺利使用云系统。

2. 最小化分离环境操作时间。 当组件以后可以移动到云，但不能立即迁移到云时，请记录其连接和数据流与云系统。 使用时间线和风险管理方法创建明确的计划，以减少工作负载在两个环境中运行的时间。 请考虑延迟迁移，直到更多组件可以一起移动。

3. 有效地连接环境。 使用 API 网关、消息队列和数据同步等集成方法在云工作负载和源环境组件之间创建可靠的连接。 这些方法可减少延迟、提高安全性，并为最终将剩余组件迁移到云做好准备。

确定要迁移的工作负荷的优先级

1. 查看工作负荷详细信息。 与利益干系人合作，查看每个工作负荷的业务和技术详细信息。 确保能够很好地了解停机时间或故障影响，并符合当前业务优先级。 使用 迁移采用计划 来验证业务单元、工作负荷所有者、技术依赖项和关键性分类等详细信息。 这些详细信息有助于有效地确定工作负荷的优先级和顺序。

   Priority	业务价值	Effort	Description
   High	High	Low	迅速收益 - 优先转移以立即产生效果
   Medium-High	High	High	战略投资——确保有足够的资源，仔细规划
   Medium-Low	Low	Low	简单候选人 - 填补主要迁移之间的空白
   Low	Low	High	避免或延迟 - 将资源集中在高价值机会上

2. 从更简单的工作负荷开始，以降低风险。 开始迁移不太复杂且风险较低的工作负荷。 此方法可帮助团队在处理更具挑战性的工作负载之前获得信心并优化迁移过程。 面向具有独立体系结构和最小集成点的内部工具、开发环境或低使用率应用程序。

3. 在生产环境之前移动非生产环境。 非生产环境提供一个安全空间来测试完整的迁移过程。 在生产环境之前迁移开发、暂存和 QA 环境，以验证就绪情况。 此顺序允许团队测试配置、性能和恢复过程，而不会影响用户。 使用非生产迁移来训练运营团队。

4. 在演示初始成功后计划关键系统。 关键应用程序在迁移到 Azure 之前需要经过证实的迁移功能。 当团队向 Azure 服务展示能力时，请为以后的波次规划这些迁移。 硬件刷新周期等业务截止时间可能需要你提前设置关键应用程序的优先级，并提供更多的安全措施和延长的测试周期。

5. 包括用于测试方案的代表性复杂工作负荷。 在每个早期阶段添加一两个复杂的工作负载，以揭示任务关键型应用程序面临的挑战。 选择表示常见模式的工作负荷，例如多层应用程序或数据库依赖系统。

创建详细的迁移计划

1. 为每个迁移设置开始日期和结束日期。 包括用于测试和问题解决的缓冲区时间，以确保顺利执行。 此详细计划可降低延迟风险，并支持有效的资源规划。

2. 将日程表与业务事件保持一致。 避免在关键业务时段（如财务关闭、产品启动或假日季节）安排迁移。 这种一致性可降低业务中断的风险，并确保利益干系人的信心。

3. 使用项目管理工具跟踪进度。 使用 Azure DevOps 等工具管理依赖项、跟踪里程碑并有效地传达更改。 这些工具提供迁移进度的可见性，并支持主动解决问题。

为每个工作负荷选择迁移方法

迁移方法分为两类：需要停机时间的迁移和停机时间几乎为零的迁移。 根据工作负荷的停机时间容差和业务关键性，为每个工作负荷选择最佳迁移方法。

1. 为容忍计划内中断的工作负荷选择停机时间迁移。 停机时间迁移更简单、更快，因为它不需要源环境和目标环境之间的实时同步。 此方法适用于具有计划维护时段的非关键工作负荷，例如开发环境、测试系统或应用程序。 记录每个工作负荷的可接受停机时间，并在低使用率期间计划迁移，以最大程度地减少业务影响。

2. 为关键工作负荷选择近零停机时间迁移。 近乎零的停机时间迁移可确保关键工作负荷在转换期间通过连续数据复制和直接转换技术保持正常运行。 此方法对于面向客户的应用程序、实时事务系统或具有严格服务级别协议的工作负载至关重要。 验证工作负荷体系结构是否支持连续复制，以及网络带宽是否可以处理实时数据传输。 在非生产环境中测试连接和复制过程，以确认此迁移方法的就绪情况。

定义回滚计划

回滚计划使团队能够在部署失败或带来风险时快速逆转更改。 定义完善的计划可最大程度地减少停机时间、限制业务影响和维护系统可靠性。 在启动任何迁移或部署之前，始终建立回滚条件和过程。

1. 定义失败的部署。 与业务利益相关者、工作负荷所有者和运营团队合作，决定什么定义为失败的部署。 示例包括运行状况检查失败、性能不佳、安全问题或未满足成功指标。 此定义可确保回滚决策与组织的风险容忍度保持一致。 在部署计划中包括触发回滚的特定条件，例如 CPU 使用率限制、响应时间阈值或错误率。 此评估使回滚决策在事件期间清晰且一致。

2. 自动执行 CI/CD 管道中的回滚步骤。 使用诸如 Azure Pipelines 或 GitHub Actions 等工具自动化回滚过程。 例如，将管道配置为在运行状况检查失败时重新部署以前的版本。

3. 针对特定工作负载创建回滚说明。 开发与工作负荷类型、环境和部署方法匹配的回滚步骤。 例如，基础结构即代码部署需要重新应用以前的模板。 应用程序回滚涉及重新部署以前的容器映像。 将回滚脚本、配置快照和基础结构即代码模板附加到回滚计划。 这些资产可实现快速执行并减少对手动干预的依赖。

4. 测试回滚步骤。 模拟预生产环境中的部署失败，以验证回滚有效性。 确定并解决自动化、权限或依赖项方面的差距。 确认回滚将系统还原到稳定的已知良好状态。

5. 改进回滚策略 每次部署或回滚事件后，进行回顾会议，以评估有效和无效的方面。 根据学到的教训、体系结构更改或新工具更新回滚条件、过程和自动化。 维护文档以确保回滚策略保持最新且有效。

就迁移计划与利益相关者互动

利益干系人批准会验证迁移计划是否满足业务要求和风险容忍度。 在执行迁移之前，应获得正式批准。

1. 使用业务理由记录迁移计划。 创建一个结构化计划，其中显示了工作负荷名称、所有者、关键性、迁移方法、停机时间窗口和业务影响。 包括每种方法的理由，并解释其如何最大程度地降低风险。

2. 展示测试的回滚方案。 显示包含步骤、时间范围和成功条件的特定回滚计划。 包括自动化和手动功能。 记录预生产测试结果，以证明快速服务恢复。

3. 根据业务约束验证计划。 与利益干系人一起查看时间线，以避免关键业务周期、维护冻结和季节性高峰。 如果存在冲突，请提供具有权衡的替代选项。

4. 获取正式批准和回滚权限。 确保利益干系人对迁移计划和回滚过程进行书面批准。 定义决策机构并建立紧急通信渠道。

5. 定义成功条件并查看检查点。 设置可衡量的指标，包括性能基准、功能验证和用户验收标准。 安排正式评审点以供继续/终止决策。

后续步骤