选择云迁移策略

通过对工作负载的明确清单和理解，云采用计划必须确定对云中每个工作负荷执行的作。 有多种迁移策略，有时称为云迁移的“Rs”。 每个工作负荷都可以停用、保留、重新托管、重新托管、重新编译、重构、重新架构、重新生成或替换。 本部分将指导如何为每个工作负荷选择正确的方法，提供选项、何时选择每个工作负载以及利弊权衡。

迁移策略概述

下表概述了所有可用的云迁移策略。 使用此参考来了解每个策略的主要业务驱动因素和关键指标，这些指标指示何时将每个方法应用于工作负荷。

在迁移之前确定业务驱动因素

业务驱动因素定义工作负荷为何需要更改才能支持特定业务目标。 业务驱动因素将云采用决策与可衡量的业务价值和战略目标联系起来。 确定这些驱动程序可确保迁移工作有目的，并与组织优先级保持一致。

1. 定义业务目标。 业务目标是组织希望从云采用中实现的高级成果，例如采用 AI、提高敏捷性、加速创新、降低成本和提高复原能力。 这些目标为所有迁移决策提供了战略上下文。 使用战略规划文档、高管面试或业务案例研讨会来识别和验证这些目标与利益干系人。

2. Identify gaps. 执行高级别差距分析，了解每个工作负荷必须更改哪些内容，以便更好地支持定义的业务目标。 此分析应考虑当前的性能、可伸缩性、合规性、用户体验和体系结构限制。 记录阻止工作负荷完全启用所需结果的任何不足。

3. 确定业务驱动因素。 业务驱动因素从工作负荷的当前状态与其所需未来状态之间的差距中浮出水面。 它表示更改的特定可作原因。 这些驱动程序指导选择适当的迁移策略。

   Business driver	Migration strategy
   需要停用冗余或低价值的工作负载	Retire
   需要最小化业务中断，并且近期不需要现代化。	Rehost
   需要 PaaS 解决方案和最少的代码更改来卸载维护并促进可靠性	Replatform
   需要代码更改以减少技术债务或优化云代码	Refactor
   需要体系结构更改才能解锁云原生功能	Rearchitect
   需要 SaaS/AI 解决方案来简化操作	Replace
   需要新的云原生解决方案来满足要求	Rebuild
   需要稳定性，无需更改	Retain

选择正确的迁移策略

迁移策略定义每个工作负荷如何根据其业务驱动因素转换到 Azure。 查看缩小策略列表，并使用业务和技术利益干系人验证所选选项。 删除与合规性、安全性或操作约束冲突的选项。 在完成策略时，请考虑 Azure 就绪情况、团队技能和集成复杂性。

1. 退休 （退役）

停用不再提供业务价值的工作负载。 当工作负荷已过时、未使用或冗余时，此策略非常重要。 通过确认工作负荷已过时且没有影响其他系统的关键依赖项来验证此决策。 更新清单以便停用工作负载。

2. 重新托管 （等效迁移）

重新托管策略通过将工作负载移动到 Azure，只需进行最少的更改即可实现快速和低风险的迁移。 重新托管是一种等同迁移，将虚拟机迁移到 IaaS，将 IaaS 迁移到 IaaS，将 PaaS 迁移到 PaaS。

1. 不要重新托管有问题的工作负荷。 重新托管无法解决现有的性能、可靠性或体系结构问题。 在没有现代化的情况下迁移此类工作负载可能会累积技术债务，并在稍后需要重新调整。 相反，在迁移过程中对这些工作负荷进行现代化，以解决根本原因。

2. 确认工作负荷在两年内不需要升级。 仅当你确信工作负荷保持其当前状态至少两年时，重新托管才适用。 如果现代化可能，请考虑重构或重新构造以避免重复工作。

3. 使用再托管构建云基础运营。 重新托管可帮助团队获得 Azure 运营、治理和成本管理的经验。 这种早期曝光支持更广泛的云采用目标，并为更复杂的现代化工作做好准备。

3. Replatform （现代化托管环境）

通过最少的代码更改，平台迁移将工作负载转移到新式托管环境。 如果想要减少基础结构管理、提高可伸缩性和简化作，而无需完全重写应用程序，则此策略非常重要。

选择使用 PaaS 选项来降低运营开销、提高可靠性或简化灾难恢复的工作负荷。 利用 PaaS 服务可能需要最少的代码重构。

4. 重构 （现代化代码）

重构可改进代码的内部结构，而无需添加新功能。 在云采用期间，这种做法非常重要，因为它有助于团队现代化旧代码、减少技术债务，并为 Azure 中的长期可维护性准备工作负载。 迁移过程创建解决技术债务的独特机会或迁移后行为显示改进领域时，应重构代码。

5. 重新架构 （现代化体系结构和代码）

重新架构策略重新设计了工作负荷的体系结构，以提高可伸缩性、敏捷性和服务方向。 当需要分解整体式应用程序、采用微服务或启用目标缩放时，此策略非常重要。 当当前体系结构限制实现业务目标或有效缩放的能力时，应重新架构。 有关示例，请参阅 新式 Web 应用模式。

6.替换（使用 SaaS 替代项）

替换策略使用商业 SaaS 解决方案来消除对自定义开发和持续维护的需求。 当 SaaS 产品/服务满足业务需求时，此策略非常理想，只需进行最少的自定义。 当 SaaS 解决方案提供可比的功能、集成功能满足要求和总拥有成本证明转换合理时，替换工作负载。 在评估替换选项时，请考虑数据迁移复杂性、用户训练需求和处理更改。 常见的替代方案包括 CRM 系统、HR 平台和协作工具，其中 SaaS 成熟度为自定义解决方案提供了可靠的替代方案。

7. 重新构建（构建云原生应用）

重新生成策略是使用云原生解决方案完全重新开发工作负荷。 当旧系统过时或现代化不可行时，此方法是合适的。 可以重新构想解决方案，以利用 PaaS、自动化和 AI 等 Azure 功能，而不是对旧功能进行现代化改造。 某些工作负荷需要重新生成，例如 DHCP 服务器。 对于其他工作负荷，最好在 Azure 中部署新的服务实例，而不是迁移它们，例如 Active Directory 域控制器。

8. 保留 （按原样保留）

在工作负载稳定、合规且满足所有当前和未来的业务需求时，保留策略将工作负荷保留在当前环境中，且无需近期驱动因素即可移动。 必须保留由于法规约束、技术依赖项或业务连续性要求而无法迁移的工作负荷。 使用 Azure Arc 管理 Azure 中保留的本地工作负荷，提供统一管理功能。 考虑一个更现代的本地解决方案，例如 Azure 本地 工作负载并连接到 Azure。 将无法迁移到另一个迁移波次的任务转移，或者在条件变化时稍后重新评估这些任务。

了解何时在迁移过程中实现现代化

迁移过程中的现代化是指重新架构、重新架构或重构工作负载，以最大化云价值。 现代化可提供长期优势，但对迁移时间线带来了复杂性和风险。 必须根据明确的业务理由评估是在迁移期间实现现代化，还是将现代化推迟到迁移后阶段。 遵循以下建议：

1. 在团队具备所需的技能和时间时实现现代化。 在没有足够专业知识或时间的情况下尝试现代化会增加风险和延迟。 如果团队缺乏就绪性，请将现代化推迟到后面的阶段。

2. 使需要兼容性更新的工作负载现代化。 旧式技术、不支持的 SDK，或者需要采用 SaaS 解决方案可能需要现代化。 使用明确的业务案例来证明每项工作都是合理的。

3. 当迁移推动资金和一致性时，实现现代化。 迁移项目通常能够获得资金及利益相关者的支持。 使用此机会使现代化与业务优先级保持一致。 延迟可能会导致低效的工作负荷和错过的机会。

向利益干系人传达决策

清晰的沟通可确保所有利益干系人在整个采用过程中了解和支持迁移决策。 利益干系人一致性通过建立对优先级和约束的共享理解来降低执行风险并改善项目结果。 必须建立结构化通信计划，以在整个迁移过程中保持一致。 遵循以下建议：

1. 定义验证业务结果的成功指标。 成功指标量化所选作的值，并确认是否实现了业务驱动因素。 此步骤可确保决策基于业务价值而不是技术完成。 使用指标，例如：

   云迁移策略	示例成功指标
   Retire	• 在迁移之前停用 100% 标识为已过时的工作负荷
   Rehost	• 将第 1 层工作负荷的 100 个% 从其他云迁移到 Azure，且不会降低服务级别协议（SLA） • 迁移后退役 30% 的本地基础设施。
   Replatform	• 为已迁移的应用程序减少 30% 的部署提前期 • 在 12 个月内将基础结构和许可成本减少 25%
   Refactor	• 使用 Azure 本机服务将应用程序响应时间提高 40% • 通过代码检测实现 95% 可观测性覆盖率
   Rearchitect	• 支持 2 倍用户负载，且性能不下降 • 将三个新的 Azure 本机服务集成到现有体系结构中
   Replace	• 将 CRM 转换为具有 99.9% 运行时间且无自定义代码的 SaaS • 将 30% 的开发精力转移到竞争优势上。
   Rebuild	• 三个月内启动新的云原生应用程序，而在本地部署则需六个月时间 • 使用 PaaS 服务将运营成本削减 40%
   Retain	• 保持当前的服务水平协议 (SLA) 和合规性状态 • 使用 Azure Arc 管理 Azure 中的本地工作负荷

2. 与所有相关利益干系人记录和共享工作负荷处理决策。 迁移决策可能会影响多个组织职能，需要广泛的利益干系人意见。 在决策沟通中包括业务所有者、法律团队、安全团队和技术主管。 说明每个迁移策略决策如何支持记录的业务目标，并解决利益干系人的担忧。

3. 与云策略团队协调迁移计划。 云策略团队提供组织上下文，并确保迁移决策与更广泛的云采用目标保持一致。 定期协调可防止单个工作负荷决策与企业范围的云策略之间的冲突。 根据策略阶段建立的云采用计划查看迁移策略选择，以保持一致性。

4. 在授权所有者和执行团队之间建立定期沟通。 决策者与实施者之间的持续沟通可确保随着技术现实的出现，计划仍然可行。 计划定期进度评审，以跟踪迁移进度、识别风险并解决技术问题。 使用此反馈循环在实施挑战或出现新机会时调整迁移策略。

5. 根据不断变化的要求查看和更新迁移策略。 在整个迁移过程中，业务优先级和技术见解发生变化，需要策略调整。 建立定期评审周期，根据当前业务目标和技术能力重新评估工作负荷处理决策。 更新策略映射，以反映新优先级、吸取的教训和不断变化的组织需求。

Next steps