投资组合分析和迁移规划

为应用程序组合和相关基础设施建立基准 — 迭代投资组合级别的数据，从发现加速和初始规划阶段开始构建，以缩小差距并生成整个应用程序组合的高级视图。在这个阶段，关键是完善应用程序到基础架构的映射、使用数据和应用程序元数据属性。这些属性包括每个应用程序的所有权、重要性和主要功能。

获取和分析依赖关系数据（通常使用专门的发现工具）— 为了验证应用程序并帮助制定迁移浪潮计划，在此阶段，高度可信的应用程序依赖性数据是关键。依赖关系数据包括通信数据，例如系统之间的通信量和频率，以及非技术依赖性，例如操作注意事项。这些依赖关系决定了哪些应用程序必须同时移动，哪些应用程序可以从不同的位置运行。

识别和验证合规性和监管要求 — 确定和验证框架、规则、证据和文档要求。 

将假设转化为事实 — 在前几个阶段假设了多少？ 在这个阶段，关键是将假设数量减少到最低限度。

为迁移组合合理化模型建立基准 — 迭代前几个阶段的模型（例如，应用程序优先级标准和 6 R 决策树）。通过将模型应用于整个应用程序组合来验证模型。

记录可衡量的业务成果 — 为了使迁移浪潮与业务目标保持一致，为每个迁移浪潮确定业务结果和相关的关键主要指标 (KPI)。

发展方向性业务案例 — 用实际利用率和成本数据取代基准，并根据更新的浪潮计划完善迁移成本。扩大覆盖范围，将每项预期业务成果的全部预期价值包括在内，例如降低成本、提高 IT 工作效率、增强弹性和提高灵活性。

记录和传达关键日期 — 记录和传达重要事件（例如数据中心退出日期、合同和许可协议续订）、应用程序发布周期、要避免的迁移日期、技术更新周期和人员可用性。

分析波浪规划的成本和风险 — 可以支持或容忍多少并行变更？ 分析人员需求、风险识别和缓解、关键程度和影响。

确定技能要求 — 支持云中不同工作负载类型的预计准备程度如何？ 迁移浪潮计划是否与预计的准备情况一致？ 支持团队能否满足波浪计划的要求？

记录内部流程 — 记录影响云迁移的当前流程的信息，例如变更管理、服务管理、架构审查委员会、风险评估和批准工作流程。

创建迁移浪潮计划-要创建迁移计划，请合并此列表中先前讨论的所有要素。将优先级标准应用于投资组合，并分析依赖关系以创建申请浪潮。将平台和迁移准备情况纳入迁移浪潮计划。实施 AWS 基础设施和服务需要多长时间？ 安全和运营准备需要什么？ 对波浪持续时间有什么影响？ 实施迁移工具需要多长时间？ 考虑到网络和系统的使用情况，复制数据需要多长时间？ 什么是切换窗口？ 回滚需要多长时间？

更新工作流 — 建立流程，将产品组合和详细的应用程序评估数据输入到迁移和着陆区工作流中。确保这些工作流清楚地概述其数据需求。

High-fidelity 应用程序和基础架构清单

High-level 每个应用程序的迁移策略

详细业务案例

High-confidence 迁移浪潮计划

确保应用程序在迁移浪潮计划中均匀分布。考虑关键性和复杂性，以避免可能造成障碍或延迟迁移的复杂性。

在前两波浪潮中优先考虑非关键、简单的应用程序。

专注于将优先级、依赖关系和业务驱动因素相结合，以迭代波浪计划。

在制定浪潮计划时，请考虑云基础架构、安全性和运营就绪性（包括技能）。

制定波浪计划，使迁移浪潮的持续时间（通常为 4-8 周）概述申请历程。每波都应涵盖以下内容：