本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 优先级划分和迁移策略
<a name="prioritization-and-migration-strategy"></a>

移民规划的一个关键要素是确定优先顺序的标准。本练习的重点是要了解应用程序的迁移顺序。该策略是采取迭代和渐进的方法来发展优先级划分模型。

## 确定应用程序的优先级
<a name="prioritizing-applications"></a>

此评估阶段的重点是建立初始标准，以确定低风险和低复杂性工作负载的优先级。这些工作负载非常适合试点应用程序。在初始迁移中使用低风险、低复杂性的工作负载可以降低风险，让团队有机会获得经验。这些标准将在进一步的评估阶段进行改进，以便在制定迁移浪潮计划时将优先顺序与业务驱动因素保持一致。

初始标准应优先考虑依赖关系较少、在云支持的基础架构中运行的应用程序以及来自非生产环境的应用程序。例如，具有 0—3 个依赖关系的应用程序准备好在开发或测试环境中按原样重新托管。这些标准适用于定义试点应用程序以及可能的第一轮和第二轮迁移浪潮，具体取决于云采用的成熟度和可信度。

*决定使用什么初始标准*

选择 2-10 个数据点用于确定首批工作负载的优先级。这些数据点来自您的初始应用程序和基础设施清单（请参阅[数据收集](initiating-data-collection.md)部分）。

接下来，为每个数据点的每个可能值定义分数或权重。例如，如果选择了环境属性，并且可能的值为生产、开发和测试，则会为每个值分配一个分数，这个数字越大表示优先级越高。尽管它是可选的，但我们建议为每个数据点分配重要性或相关性的乘法系数。此可选步骤提供了更高级别的差异化因素，以强调哪些更重要，这有助于在迭代为值分配分数时保持标准一致。

根据在前几个迁移浪潮中优先考虑低风险、简单的应用程序的策略，下表显示了示例属性选择及其值分配。


| **属性（数据点）** | **可能的值** | **分数 (0-99)** | **重要性或相关性乘法因子** | 
| --- |--- |--- |--- |
| 环境 | 测试 | 60 | 最高 (1 倍) | 
| 开发 | 40 | 
| 生产 | 20 | 
| 业务重要性 | 低 | 60 | 最高 (1 倍) | 
| 中 | 40 | 
| 高 | 20 | 
| 监管或合规框架 | 无 | 60 | 最高 (1 倍) | 
| FedRAMP | 10 | 
| 操作系统支持 | 云端就绪 | 60 | 中高 (0.8 倍) | 
| 云端不支持 | 10 | 
| 计算实例的数量 | 1-3 | 60 | 中高 (0.8 倍) | 
| 4-10 | 40 | 
| 11 或更多 | 20 | 
| 迁移策略 | 重新托管 | 70 | 中号 (0.6 倍) | 
| 更换平台 | 30 | 
| 重构或重新架构 | 10 | 

确保您选择的属性可以作为应用程序之间的关键区别。否则，该标准将导致许多工作负载共享相同的优先级。应用模型后，我们建议您查看结果排名的顶部和底部，看看您是否同意。如果您普遍不同意，则可以重新审视用于对工作负载进行评分的标准。

获得排名后，请查看整个投资组合中的分数分布。分数本身并不重要。重要的是分数之间的差异。例如，您可能会发现最高的总分是 8,000，最低的分数是 800。考虑将生成的分数绘制为直方图，这样您就可以验证您的分布是否良好。理想的分布看起来像标准的钟形曲线，有一些非常高优先级的工作负载和一些非常低优先级的工作负载。大多数应用程序将处于中间位置。

初始优先级排序的另一个关键方面是将有兴趣成为云的早期采用者的内部团队或业务部门包括在内。这可能是获得业务支持以迁移给定应用程序的重要杠杆，尤其是在早期。如果您的组织中出现这种情况，请在上表中包括业务部门属性。为愿意提出申请的业务部门打高分。使用业务部门属性将有助于将这些应用程序置于列表的顶部。

在您同意由此产生的排名后，选择前 5-10 个应用程序。这些将是您的初始应用程序迁移候选人。完善列表，以便您确认 3 到 5 个应用程序。这可以帮助您在执行详细的应用程序评估时采取有针对性的方法。有关更多信息，请参阅[按优先顺序排列的应用程序评估](prioritized-applications-assessment.md)。

 

## 确定要迁移的 R 类型
<a name="migration-r-type"></a>

决定每个应用程序和相关基础架构的迁移策略将对迁移速度、成本和收益水平产生影响。关键是要根据平衡的因素组合来确定战略，包括业务驱动因素、技术指导原则、优先级标准和业务战略。

有时，这些因素会产生相互矛盾的观点。例如，迁移的主要驱动力可能是创新和敏捷性。同时，您可能需要快速降低成本。从长远来看，对范围内的所有应用程序进行现代化改造可以降低成本，但需要更多的前期投资。在这种情况下，一种方法是使用需要更少精力的策略来迁移应用程序，例如重新托管或重新平台。这可以在短期内快速提高效率并降低成本。然后，将节省的资金再投资于稍后阶段的应用程序现代化改造，从而进一步降低成本。

但是，从完全重新托管所有应用程序开始，会延迟现代化的更大好处。关键是在迁移策略之间找到平衡，以便优先考虑业务战略应用程序进行现代化，而其他应用程序可以先进行重新托管或平台重组，然后再进行现代化改造。

*如何确定应用程序的迁移策略？*

在此评估阶段，重点是纳入指导迁移策略选择的初始模型。要验证初始应用程序的迁移策略，请将模型与业务驱动因素和优先级标准结合使用。决策树的默认逻辑将帮助您确定范围的初始处理方法。在树中，最复杂的方法（例如重构或重新架构）是为你的战略工作负载保留的。

![\[本指南中讨论的 6 R 决策过程。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/application-portfolio-assessment-guide/images/6Rs-DecisionTree-baseModel.png)


此图表的可自定义 [draw.io](https://github.com/jgraph/drawio-desktop/releases) 版本可在*[附件](#attachments)*部分找到。

初始模型的第一步是使用组织定义的驱动因素更新树顶部的业务驱动因素。接下来，将树应用于应用程序组件，而不是整个应用程序。例如，对于包含三个组件（前端、应用程序层和数据库）的三层应用程序，每个组件都应独立传输树并为其分配特定的策略和模式。这是因为在某些情况下，您可能需要重新托管或重新构建给定层的平台，并重构（重新架构）其他层。

独立的组件分配将引导您为关联的基础架构定义迁移策略。基础架构策略可能与其支持的应用程序组件相同，也可能有所不同。例如，一个应用程序组件将被重新平台化为具有较新操作系统的新虚拟机，将遵循平台重组策略，而托管该组件的当前虚拟机将停用。基础架构的迁移策略是根据为应用程序组件选择的策略计算的。

在使用决策树建立迁移策略之前，请使用几个应用程序测试逻辑，看看你是否普遍同意结果。6 R 决策树是一种指南，它不能取代确定其正确性所需的分析。树逻辑可能不适用于特定情况。将这些情况视为例外，并通过记录重写的理由而不是更改树逻辑，继续推翻由树驱动的决策。这样可以防止出现多个决策树版本，这可能会变得难以管理。一般指导是，树应该对至少 70-80% 的工作负载有效。其余部分则会有例外。在这个评估阶段，对树形逻辑的任何调整都应侧重于建立初始模型。后续阶段将进行进一步的迭代和完善，例如[产品组合分析和迁移规划](portfolio-analysis-migration-planning.md)。

## 附件
<a name="attachments"></a>

[attachment.zip](samples/attachment.zip)