加快发现速度和初步规划

了解业务驱动因素

识别现有的数据来源

评估对自动发现工具的需求

为应用程序优先级划分和迁移策略选择建立基础模型

对投资组合的初步分析

确定初始迁移候选人

为移民制定有针对性的商业案例

初步计划大纲。

确定利益相关者 — 谁会受到迁移的影响？ 谁是决策者？ 谁能从这次迁移中受益？ 谁负责执行迁移？

确定业务驱动因素 — 迁移所追求的业务成果和目标是什么（例如，业务转型、成本降低、敏捷性）？ 这些信息将是决定迁移战略和优先顺序的关键因素。

识别现有的数据来源-识别并记录现有的数据来源，例如人员、工具、文档。为每个来源分配信任级别。例如，程序化或自动化来源比机构知识或文档更值得信赖。随着时间的推移，信任度较低的数据源将被信任度较高的数据源所取代。

建立应用程序和基础架构的初始清单 — 确定应用程序名称、主要功能、重要程度、IT 环境、高级合规性和监管要求以及已知的依赖关系。哪些 IT 资产与应用程序相关联？ 识别产品名称和版本、历史性能数据、已知问题和风险。

确定数据缺口和发现需求 — 分析数据缺口，评估购买自动发现工具的需求。发现工具的投资决策应以提高对数据的总体可信度为后盾，以便进行准确的分析。为了保持应用程序组合的 up-to-date视图，我们建议使用专门的工具来发现工作负载。

部署发现工具 — 采购、安装和配置发现工具（如果适用），并制定目标系统的推出计划。对所有目标系统进行为期两周的编程数据收集提供了足够的数据，以实现这一阶段的结果。但是，为了完善产出，需要在后期阶段持续收集数据。

收集总拥有成本 (TCO) 数据-使用收集的数据生成和更新 TCO 报告，并创建有针对性的商业案例。有关更多信息，请参阅 “最佳实践” 部分。

使用应用程序合理化模型-建立或采用基本的应用程序合理化模型进行迁移。包括关键应用程序属性的选择、优先级划分的权重以及基于 6 R 决策树的初始 R 类型（重新托管、重定平台、重构（重新架构）、回购、保留、停用）。

确定初始迁移候选人 — 现在可以转移哪些应用程序来建立或扩展 AWS 基础并积累经验？ 在此阶段，模型应优先考虑依赖性较低（例如，零三）的简单工作负载。 

计划正在进行的评估 — 为下一个项目组合评估活动做好计划，例如对优先工作负载进行详细评估。

计划沟通 — 为利益相关者制定沟通计划或节奏以及范围控制机制。随着迁移计划的进展，范围会发生变化是正常的。确保投资组合数据的单一真实来源，并跟踪、评估和传达范围的变化。

记录在案的业务驱动因素、成果、目标和技术指导原则。

应用程序和基础设施的初步清单，以及已确定的数据缺口。这是对投资组合的初步看法，将在后续阶段进行迭代和完善。

一个有方向性的商业案例和估计的迁移成本。

三五个作为初始迁移候选应用程序的列表。

与投资组合相关的活动、里程碑和范围变更的沟通计划。

专注于阶段目标并保持高水平的分析。采用渐进式数据收集方法，不要等到完整的数据集之后再继续前进。

避免分析瘫痪。专注于识别数据差距并推动采取行动来缩小这些差距。

购买专门的发现工具。通常通过自动化工具获得的编程数据具有更高的信任度，在书面文档、静态数据和机构知识之前，应优先考虑这些数据。

与已确定的利益相关者合作，消除阻碍因素。

为应用程序组合评估工作流程分配单线程主管。

考虑使用 Mig ration Evalutor 来处理您的定向业务案例，或者探索 AWS 合作伙伴网络工具和产品以了解总体拥有成本和 AWS定价。

考虑一下 AWS Professional Services 和 AWS 合作伙伴，它们可以帮助您加快业务成果。