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

# 加快发现速度和初步规划
<a name="portfolio-discovery-initial-planning"></a>

投资组合评估的第一阶段侧重于在投资组合层面获取和分析数据的初始步骤。主要目标是确定业务驱动因素并从应用程序和基础设施中收集一般数据，以获得投资组合的初步视图。这些数据包括高级技术和业务属性，例如应用程序名称、环境、产品版本、重要性、性能值等，如[数据需求](understanding-initial-assessment-data-requirements.md)部分所述。完成此阶段是了解项目范围、确定初始迁移候选人以及为业务案例提供信息的关键。

## 本阶段的主要结果
<a name="discovery-outcomes"></a>
+ 记录在案的业务驱动因素、成果、目标和技术指导原则。
+ 应用程序和基础设施的初步清单，以及已确定的数据缺口。这是对投资组合的初步看法，将在后续阶段进行迭代和完善。
+ 有方向性的商业案例和估计的迁移成本。
+ 初始迁移候选列表（例如，三五个应用程序）。
+ 定义了后续步骤。

# 了解初始评估数据要求
<a name="understanding-initial-assessment-data-requirements"></a>

数据收集可能需要大量时间，当不清楚需要哪些数据以及何时需要数据时，数据收集很容易成为障碍。关键是要理解对于这个阶段的结果来说，什么是太少的数据和过多的数据之间的平衡。要专注于投资组合评估的早期阶段所需的数据和保真度，请采用迭代方法进行数据收集。

## 数据源和数据要求
<a name="data-sources-data-requirements"></a>

第一步是确定您的数据来源。首先确定组织内可以满足数据要求的关键利益相关者。他们通常是服务管理、运营、容量规划、监控和支持团队的成员，以及应用程序所有者。与这些小组的成员建立工作会议。沟通数据要求并获取可提供数据的工具和现有文档的列表。

要指导这些对话，请使用以下一组问题：
+ 当前基础架构和应用程序库存的准确性和最新性如何？ 例如，对于公司配置管理数据库 (CMDB)，我们是否已经知道差距在哪里？
+ 我们是否有活跃的工具和流程来保持 CMDB（或等效工具）的更新？ 如果是，它的更新频率有多高？ 最新的刷新日期是什么时候？
+ 当前清单（例如 CMDB）是否包含 application-to-infrastructure映射？ 每项基础设施资产是否都与应用程序相关联？ 每个应用程序是否都映射到基础架构？
+ 库存中是否包含每种产品的许可证和许可协议目录？
+ 清单中是否包含依赖关系数据？ 注意存在通信数据，例如服务器到服务器、应用程序到应用程序、应用程序或服务器到数据库。
+ 环境中还有哪些其他工具可以提供应用程序和基础架构信息？ 请注意是否存在可用作数据源的性能、监控和管理工具。
+ 托管我们的应用程序和基础设施的不同位置有哪些，例如数据中心？

回答完这些问题后，请列出您已识别的数据来源。然后为他们每个人分配一个忠诚度或信任级别。最近（30 天内）从活跃的程序来源（例如工具）中验证的数据具有最高的保真度。静态数据被认为保真度较低，可信度较低。静态数据的示例包括文档、工作簿、手动更新的 CMDBs数据或任何其他非编程维护的数据集，或者其上次刷新日期超过 60 天的数据集。

下表中的数据保真度级别仅作为示例。我们建议您评估组织对假设的最大容忍度以及相关风险的要求，以确定什么是适当的保真度。在表中，机构知识是指任何未记录在案的有关应用程序和基础设施的信息。


| **数据源** | **保真度等级** | **投资组合覆盖范围** | **注释** | 
| --- |--- |--- |--- |
| 机构知识 | 低-最多 25% 的准确数据、75% 的假设值或数据超过 150 天。 | 低 | 稀缺，专注于关键应用程序 | 
| 知识库 | 中低——35-40％的准确数据，65-60％的假设值或数据存在120-150天。 | 中 | 手动维护，细节层次不一致 | 
| CMDB | 中-大约 50% 的准确数据，大约 50% 的假设值或数据已存在 90-120 天。 | 中 | 包含来自混合来源的数据，多个数据缺口 | 
| VMware vCenter 导出 | 中高——75-80% 的准确数据，25-20% 的假设值或数据的存在时间为 60-90 天。 | 高 | 覆盖 90% 的虚拟化资产 | 
| 应用程序性能监控 | 高-大部分数据是准确的，假设值约为 5% 或数据已有 0-60 天的时间。 | 低 | 仅限于关键生产系统（占应用程序组合的 15%） | 

下表指定了每个资产类别（应用程序、基础架构、网络和迁移）、特定活动（清单或业务案例）的必需和可选数据属性，以及此评估阶段的建议数据保真度。这些表使用以下缩写：
+ R，表示必填项
+ (D)，用于方向性业务案例，需要进行总拥有成本 (TCO) 比较和定向业务案例
+ (F)，用于全方位业务案例，用于总体拥有成本比较和定向业务案例（包括迁移和现代化成本）
+ O，表示可选
+ 不适用，因为不适用

**应用程序**


| **属性名称** | **描述** | **库存和优先顺序排列** | **业务案例** | **建议的保真度（最低）** | 
| --- |--- |--- |--- |--- |
| 唯一标识符 | 例如，应用程序 ID。通常适用于现有 CMDBs或其他内部库存和控制系统。 IDs 如果您的组织中未定义这些内容，请考虑创建唯一值。 | R | R (D) | 高 | 
| 应用程序名称 | 您的组织知道此应用程序的名称。如果适用，请包括商业 off-the-shelf (COTS) 供应商和产品名称。 | R | R (D) | 中高 | 
| 是 COTS 吗？ | 是或否。 无论是商业应用程序还是内部开发 | R | R (D) | 中高 | 
| COTS 产品和版本 | 商用软件产品名称和版本  | R | R (D) | 中 | 
| 说明 | 主要应用程序功能和上下文 | R | O | 中 | 
| 严重性 | 例如，战略或创收应用程序，或支持关键功能 | R | O | 中高 | 
| Type | 例如，数据库、客户关系管理 (CRM)、Web 应用程序、多媒体、IT 共享服务 | R | O | 中 | 
| 环境 | 例如，生产、预制版、开发、测试、沙箱 | R | R (D) | 中高 | 
| 合规与监管 | 适用于工作负载的框架（例如 HIPAA、SOX、PCI-DSS、ISO、SOC、FedRAMP）和监管要求 | R | R (D) | 中高 | 
| 依赖项 | 内部和外部应用程序或服务的上游和下游依赖关系。非技术依赖关系，例如操作要素（例如维护周期） | O | O | 中低 | 
| 基础设施映射 | 映射到构成应用程序的物理 and/or 虚拟资产 | O | O | 中 | 
| 许可证 | 商用软件许可证类型（例如，微软 SQL Server Enterprise） | O | R | 中高 | 
| 成本 | 软件许可、软件操作和维护成本 | 不适用 | O | 中 | 

**基础设施**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **属性名称** | **描述** | **库存和优先顺序排列** | **业务案例** | **建议的保真度（最低）** | 
| 唯一标识符 | 例如，服务器 ID。通常适用于现有 CMDBs 或其他内部库存和控制系统。 IDs 如果您的组织中未定义这些内容，请考虑创建唯一值。 | R | R | 高 | 
| 网络名称 | 网络中的资产名称（例如，主机名） | R | O | 中高 | 
| DNS 名称（完全限定域名或 FQDN） | DNS 名称 | O | O | 中 | 
| IP 地址和网络掩码 | 内部 and/or 公有 IP 地址 | R | O | 中高 | 
| Asset type | 物理或虚拟服务器、虚拟机管理程序、容器、设备、数据库实例等 | R | R | 中高 | 
| Product name | 商业供应商和产品名称（例如， VMware ESXiIBM Power Systems、Exadata） | R | R | 中 | 
| 操作系统 | 例如，REHL 8、Windows Server 2019、AIX 6.1 | R | R | 中高 | 
| 配置 | 分配的 CPU、内核数、每个内核的线程数、总内存、存储空间、网卡 | R | R | 中高 | 
| 利用率 | CPU、内存和存储峰值和平均值。数据库实例吞吐量。 | R | O | 中高 | 
| 许可证 | 商品许可证类型（例如 RHEL 标准） | R | R | 中 | 
| 是共享基础架构吗？ | “是” 或 “否” 表示提供共享服务的基础架构服务，例如身份验证提供商、监控系统、备份服务和类似服务 | R | R (D) | 中 | 
| 应用程序映射 | 在此基础架构中运行的应用程序或应用程序组件 | O | O | 中 | 
| 成本 | 裸机服务器的满负荷成本，包括硬件、维护、操作、存储（SAN、NAS、Object）、操作系统许可证、机架空间份额和数据中心管理费用 | 不适用 | O | 中高 | 

**网络**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **属性名称** | **描述** | **库存和优先顺序排列** | **业务案例** | **建议的保真度（最低）** | 
| 管道尺寸 (Mb/s), redundancy (Y/N) | 当前广域网链路规格（例如，1000 Mb/s 冗余） | O | R | 中 | 
| 链路利用率 | 峰值和平均利用率，出站数据传输（GB/月） | O | R | 中 | 
| 延迟 (毫秒) | 连接位置之间的当前延迟。 | O | O | 中 | 
| 成本 | 每月的当前费用 | 不适用 | O | 中 | 

**迁移**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **属性名称** | **描述** | **库存和优先顺序排列** | **业务案例** | **建议的保真度（最低）** | 
| 重新托管 | 客户和合作伙伴每项工作量（人日）、客户和合作伙伴每天的成本费率、工具成本、工作负载数量 | 不适用 | R (F) | 中高 | 
| 更换平台 | 客户和合作伙伴为每项工作负载付出的努力（人日）、客户和合作伙伴每天的成本费率、工作负载数量 | 不适用 | R (F) | 中高 | 
| 重构 | 客户和合作伙伴为每项工作负载付出的努力（人日）、客户和合作伙伴每天的成本费率、工作负载数量 | 不适用 | O | 中高 | 
| 停用 | 服务器数量，平均停用成本 | 不适用 | O | 中高 | 
| 登录区 | 重复使用现有的 (Y/N)、所需 AWS 区域列表、成本 | 不适用 | R (F) | 中高 | 
| 人与变革 | 接受云运营和开发培训的员工人数、每人培训成本、每人培训时间成本 | 不适用 | R (F) | 中高 | 
| Duration | 范围内工作负载迁移的持续时间（月） | O | R (F) | 中高 | 
| 并行成本 | 迁移期间可以消除原样成本的时间范围和比率 | 不适用 | O | 中高 | 
| 迁移期间推出 AWS 产品和服务的时间范围和速度以及其他基础设施成本 | 不适用 | O | 中高 | 

## 评估对发现工具的需求
<a name="discovery-tooling"></a>

您的组织需要发现工具吗？ 产品组合评估需要高度可信的应用程序和基础架构 up-to-date数据。投资组合评估的初始阶段可以使用假设来填补数据空白。

但是，随着进展的推进，高保真数据可以制定成功的迁移计划并正确估计目标基础架构，从而降低成本并最大限度地提高收益。它还通过启用考虑依赖关系的实施来降低风险，并避免迁移陷阱。云迁移计划中发现工具的主要用例是通过以下方式降低风险并提高数据的可信度：
+ 自动或编程数据收集，生成经过验证、高度可信的数据
+ 加快数据获取速度，提高项目速度并降低成本
+ 提高了数据的完整性，包括通信数据和依赖关系中通常不可用 CMDBs
+ 获取诸如自动应用程序识别、TCO 分析、预计运行率和优化建议等见解
+ 高可信度的迁移浪潮规划

当不确定系统是否存在于给定位置时，大多数发现工具可以扫描网络子网并发现那些响应 ping 或简单网络管理协议 (SNMP) 请求的系统。请注意，并非所有网络或系统配置都允许 ping 或 SNMP 流量。与您的网络和技术团队讨论这些选项。

应用程序组合评估和迁移的后续阶段在很大程度上依赖于准确的依赖关系映射信息。依赖关系映射可让您了解中所需的基础设施和配置 AWS （例如安全组、实例类型、账户放置和网络路由）。它还有助于对必须同时移动的应用程序（例如必须通过低延迟网络进行通信的应用程序）进行分组。此外，依赖关系映射为业务案例的发展提供了信息。

在决定使用发现工具时，重要的是要考虑评估过程的所有阶段并预测数据需求。数据缺口有可能成为障碍，因此通过分析未来的数据需求和数据源来预测这些缺口是关键。该领域的经验表明，大多数停滞不前的迁移项目都有一个有限的数据集，其中无法清楚地识别范围内的应用程序、相关的基础设施及其依赖关系。这种缺乏识别可能导致错误的指标、决策和延迟。获取 up-to-date数据是成功迁移项目的第一步。

*如何选择发现工具？*

市场上有几种发现工具提供了不同的特性和功能。考虑您的要求。然后决定最适合您的组织的选项。在决定迁移发现工具时，最常见的因素如下：

*安全性*
+ 访问工具数据存储库或分析引擎的身份验证方法是什么？ 
+ 谁可以访问数据，以及访问该工具的安全控制措施有哪些？ 
+ 该工具如何收集数据？ 它需要专用凭证吗？ 
+ 该工具需要什么凭证和访问级别才能访问我的系统和获取数据？ 
+ 如何在刀具组件之间传输数据？ 
+ 该工具是否支持静态和传输中的数据加密？ 
+ 数据是集中在我的环境内部还是外部的单个组件中？ 
+ 网络和防火墙要求是什么？ 

确保安全团队参与有关发现工具的早期对话。

*数据主权*
+ 数据存储和处理在哪里？ 
+ 该工具是否使用软件即服务 (SaaS) 模式？ 
+ 它是否有可能将所有数据保留在我的环境范围内？ 
+ 能否在数据离开我的组织边界之前对其进行筛选？ 

根据数据驻留要求考虑您的组织需求。

*架构*
+ 需要什么基础架构，有哪些不同的组件？
+ 是否有多个架构可用？ 
+ 该工具是否支持在气锁安全区域中安装组件？

*性能*
+ 数据收集对我的系统有什么影响？ 

*兼容性和范围*
+ 该工具是否支持我的全部或大部分产品和版本？ 查看工具文档，根据有关您的范围的当前信息来验证支持的平台。
+ 我的大多数操作系统是否支持数据收集？ 如果您不知道自己的操作系统版本，请尝试将发现工具列表的范围缩小到支持系统范围更广的版本。

*收集方法*
+ 该工具是否需要在每个目标系统上安装代理？
+ 它是否支持无代理部署？ 
+ 代理和无代理提供相同的功能吗？ 
+ 收款流程是怎样的？

*功能*
+ 有哪些可用的功能？ 
+ 它能否计算出总拥有成本 (TCO) 和估计的 AWS 云 运行率？ 
+ 它是否支持迁移规划？ 
+ 它能衡量绩效吗？ 
+ 它能否推荐目标 AWS 基础架构？ 
+ 它会执行依赖关系映射吗？ 
+ 它提供了什么级别的依赖关系映射？ 
+ 它是否提供 API 访问权限？ （例如，能否通过编程方式访问它来获取数据？）

考虑具有强大的应用程序和基础架构依赖关系映射功能的工具，以及那些可以从通信模式中推断出应用程序的工具。

*成本*
+ 许可模式是什么？ 
+ 许可费用是多少？ 
+ 是每台服务器的定价吗？ 是分层定价吗？ 
+ 是否有任何功能有限的选项可以按需授权？ 

发现工具通常用于迁移项目的整个生命周期。如果您的预算有限，请考虑至少 6 个月。但是，缺少发现工具通常会导致更高的手动工作量和内部成本。

*Support 模型*
+ 默认提供什么级别的支持？ 
+ 有支持计划吗？ 
+ 事件响应时间是多少？

*专业服务*
+ 供应商是否提供专业服务来分析发现结果？ 
+ 他们能否涵盖本指南的内容？ 
+ tooling \$1 服务有折扣或捆绑包吗？

**提示**  
要查找和评估发现工具，请使用[发现、规划和推荐](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/)网站。

*发现工具的推荐功能*

为避免随着时间的推移配置和合并来自多个工具的数据，发现工具应涵盖以下最低功能：
+ **软件**-发现工具应该能够识别正在运行的进程和已安装的软件。
+ **依赖关系映射** — 它应该能够收集网络连接信息，并构建服务器和正在运行的应用程序的入站和出站依赖关系图。此外，发现工具应该能够根据通信模式从基础架构组中推断出应用程序。
+ **配置文件和配置发现** — 它应该能够报告基础架构配置文件，例如 CPU 系列（例如 x86、PowerPC）、CPU 核心数量、内存大小、磁盘数量和大小以及网络接口。
+ **网络存储发现** — 它应该能够检测和分析来自网络连接存储 (NAS) 的网络共享。
+ **性能**-它应该能够报告 CPU、内存、磁盘和网络的峰值和平均利用率。
+ **差距分析** — 它应该能够提供有关数据数量和保真度的见解。
+ **网络扫描** — 它应该能够扫描网络子网并发现未知的基础架构资产。
+ **报告** — 它应该能够提供收集和分析状态。
+ **API 访问权限** — 它应该能够提供编程方式来访问收集的数据。

*需要考虑的其他功能*
+ **TCO 分析**，用于对当前本地成本和预计 AWS 成本进行成本比较。
+ 在重新托管和平台方案中，为微软 SQL Server 和 Oracle 系统提供@@ **许可分析和优化建议**。
+ **迁移策略建议**（发现工具能否根据当前技术提出默认的迁移 R 类型建议？）
+ **库存导出**（格式为 CSV 或类似格式）
+ **合理调整规模的建议**（例如，它能否映射推荐的目标 AWS 基础架构？）
+ **依赖关系可视化**（例如，依赖关系映射能否在图形模式下可视化？）
+ **建筑视图**（例如，可以自动生成建筑图吗？）
+ **应用程序优先级**（它能否为应用程序和基础设施属性分配权重或相关性，以创建迁移的优先级标准？）
+ **波浪规划**（例如，推荐的应用程序组和创建迁移浪潮计划的能力）
+ **迁移成本估算**（迁移工作量估算）

*部署注意事项*

选择并购买了发现工具后，请考虑以下问题，以推动与负责在组织中部署该工具的团队的对话：
+ 服务器或应用程序是否由第三方运营？ 这可能决定要参与的团队和要遵循的流程。
+ 获得批准部署发现工具的高级流程是什么？
+ 访问服务器、容器、存储和数据库等系统的主要身份验证过程是什么？ 服务器凭证是本地的还是集中的？ 获取证书的流程是怎样的？ 需要凭据才能从您的系统（例如，容器、虚拟或物理服务器、虚拟机管理程序和数据库）收集数据。获取用于连接每项资产的发现工具的凭证可能具有挑战性，尤其是在这些资产未集中化的情况下。
+ 网络安全区域的轮廓是什么？ 网络图是否可用？
+ 在数据中心请求防火墙规则的流程是什么？
+ 当前与数据中心运营（发现工具安装、防火墙请求SLAs）相关的支持服务级别协议 () 是什么？

# 业务驱动因素和技术指导原则
<a name="business-drivers-technical-guiding-principles"></a>

## 业务驱动因素
<a name="business-drivers"></a>

无论您的组织已经决定迁移到云端还是即将做出这一决定，定义和记录云迁移的业务驱动因素都将阐明迁移的原因。记录原因后，您可以定义要迁移的内容以及迁移的方式。这项活动很重要。我们建议尽早进行此项工作，以便为后续步骤提供信息和指导。

确定应参与讨论的利益相关者，以记录驱动因素。通常是组织内部的高级管理人员和关键技术负责人，以及您自己的客户。 CxOs尽管您的客户不太可能参与此次讨论，但我们建议在您的组织中指定一个或多个人员来代表客户的观点和目标。

业务驱动因素应与可在整个迁移过程中进行衡量的指标相关联，以验证是否已实现成果。公司的战略目标和年度报告可以作为起点。

根据现有和预计的指标，将对话重点放在公司迁移到云端后想要达到的目标上。考虑目标和业务成果。另外，请考虑随着云采用率的提高，成功会是什么样子。

接下来，确定每个驱动因素的重要性级别。优先事项是什么？ 预期的好处有哪些？ 收益如何支持业务目标和成果？ 在应用程序组合评估的背景下，答案将有助于确定迁移工作负载的优先顺序并制定技术指导原则。但是，业务驱动因素将定义和影响整个迁移计划。

## 技术指导原则
<a name="technical-guiding-principles"></a>

技术指导原则为投资组合评估后期阶段的迁移策略选择提供了依据。在现阶段，重点是识别它们。

可以将指导原则确立为从业务目标和结果中得出的与技术有关和方法相关的一般决策。

例如，一家公司的主要目标是降低成本，而预期的结果是在 6-12 个月的给定日期之前关闭本地数据中心。由此产生的指导原则是，尽可能使用重新托管或重新定位迁移策略，将所有应用程序迁移到云端。在这种情况下，该 lift-and-shift方法可以加快短期迁移的结果。应用程序迁出本地数据中心后，公司可以专注于主要业务驱动因素，以优化迁移的工作负载或实现现代化。

要制定技术指导原则，首先要分析业务驱动因素。确定可实现业务目标和结果的技术和技术清单。接下来，完善列表并根据适用性或偏好分配相关性顺序，以实现预期的结果。

记录指导原则，并与参与规划和执行迁移的人员进行沟通。强调原则与实际实施之间的担忧和潜在冲突。

下表提供了业务驱动因素和技术指导原则的示例。


| **业务驱动因素** | **结果** | **Metrics** | **技术指导原则** | 
| --- |--- |--- |--- |
| 加快创新。 | 提高竞争力，提高业务灵活性 | 每天或每月的部署次数、每季度发布的新功能、客户满意度得分、实验次数 | 通过使用微服务和 DevOps 运营模型重构差异化应用程序，以提高敏捷性和新功能的上市速度。 | 
| 降低运营和基础设施成本。 | 供需匹配，成本基础弹性（按实际用量付费） | 支出随时间推移而变化 | 1. 调整基础架构规模，重新托管应用程序。2. 淘汰利用率低或没有利用率的应用程序。 | 
| 提高运营弹性。 | 延长正常运行时间，缩短平均恢复时间 | SLAs，事件数量 | 1. 将应用程序平台改为最新、最受支持的操作系统版本。2. 为关键应用程序实施高可用性架构。 | 
| 退出数据中心。 | 在 6-12 个月内关闭数据中心 | 服务器迁移速度 | 使用云迁移工厂解决方案重新托管应用程序。 | 
| 留在内部，但要提高敏捷性和弹性。 | 在保持内部办公的同时，提高竞争力和正常运行时间 | 每天或每月的部署次数、每季度发布的新功能 SLAs、事件数量 | 1. 通过将系统的功能扩展到云端，实现系统的现代化。2. 评估是否需要重新托管或将平台重新托管到. AWS Outposts | 

# 启动数据收集
<a name="initiating-data-collection"></a>

数据收集是从应用程序和基础设施收集元数据的过程。该过程在评估的所有阶段都是反复进行的。在每个阶段，数据数量和保真度都会增加。在这一阶段，重点是收集有助于建立初始库存的一般数据。该清单将用于创建有针对性的商业案例，并确定初始迁移候选人。

确定当前数据源后，我们建议从尽可能多的系统中收集信息。有关更多信息，请参阅此阶段[的数据要求](understanding-initial-assessment-data-requirements.md)。

这种方法的好处是可以帮助更新当前的产品组合视图以及组织对其应用程序和服务的了解。它还有助于确定要移动的目标。推荐的方法是审查现有数据，例如配置管理数据库 (CMDB) 输出和信息技术服务管理 (ITSM) 系统。然后构建一份针对数据收集的资产列表。如果您的组织完全清楚迁移范围之内和范围之外的内容，则可以将数据收集限制在范围内的系统上。

在构建产品组合时，请考虑应用程序及其环境或软件发布生命周期。例如，与其识别客户关系管理 (CRM) 应用程序并指定其具有测试、开发和生产环境，不如列出三个应用程序（例如，CRM-Test、CRM-dev、CRM-Prod）。或者，使用 CRM 名称，但为每个环境分配一个唯一的 ID，并将它们作为单独的记录显示在数据存储库中。这将有助于单独规划和跟踪这些环境的迁移。例如，您可能想先迁移非生产环境。通过根据环境列出应用程序的实例，您可以清楚地管理和控制它们的过渡。

在数据收集过程中，可能不确定哪些应用程序或服务器位于给定的数据中心或源位置。在这些情况下，从现有管理工具中获取裸机和虚拟机管理程序列表会很有帮助。例如，您可以连接到虚拟机管理程序以获取要作为数据收集目标的虚拟机列表。

请注意，合并现有数据源时，初始输出可能不完整。关键是要根据这一阶段[的数据要求](understanding-initial-assessment-data-requirements.md)以及可以从现有来源获得的数据进行差距分析。将完整性百分比与数据保真度进行对比非常重要。来自低保真来源的更高的完整性级别将包含一些可能导致分析存在缺陷的假设。虽然此评估阶段不需要最高的数据保真度，但我们建议数据源至少为中高保真度。将这些数字与贵组织的风险承受能力进行对比，包括使用假设来填补数据空白。

差距分析可帮助您了解正在处理的数据的数量和质量。该分析还可以帮助您确定必须做出的假设级别，以创建有方向性的业务案例并确定要迁移的应用程序的优先顺序。发现工具可以帮助填补空白并收集高保真数据。为了提高数据的可信度并加快迁移结果，我们建议尽早部署发现工具。尽早采取行动也很重要，因为新工具的内部采购、安全和实施流程可能需要几周或几个月的时间才能完成。

我们建议在此阶段制定沟通计划或节奏以及范围变更控制机制。这可以帮助您随时向利益相关者通报情况，以便他们可以提前计划并降低风险。清晰沟通的一个关键要素是为应用程序组合和相关基础设施定义单一事实来源。避免保留多个记录系统以及应用程序和基础架构列表。将数据保存在支持版本控制和在线协作的地方（例如，数据库、工具或电子表格），并为其分配所有者。

# 优先级划分和迁移策略
<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)

# 创建有方向性的商业案例
<a name="directional-business-case"></a>

整个企业的利益相关者都应该理解并认同转型过程中的每一步的商业案例。

在早期阶段，重要的是要迅速显示出迁移计划的足够潜在价值，这样您才能获得规划和建立计划所需的资源。定向商业案例旨在提供合理的信心，让人们能够利用可以尽早收集的有限数据实现引人注目的商业价值。

计划建立后，将进一步发展商业案例。详细的案例提供了更高的准确性，更全面地了解了计划价值，并深入了解了规划优先事项。它定义和量化了组织认同的计划业务成果，并设定了基准，然后你的项目治理办公室可以据此指导计划并衡量其成就。

## 确定方向性商业案例的范围
<a name="fix-scope"></a>

定向性商业案例通常在 2-4 周内快速整理。它需要产生足够的信心，这样您才能获得足够的资源来建立核心团队，在需要时与 AWS 合作伙伴接触，并至少完成[按优先顺序排列的应用程序评估](prioritized-applications-assessment.md)和[产品组合分析以及迁移规划](portfolio-analysis-migration-planning.md)阶段。

通常，支持产品组合迁移的定向业务案例按以下方式之一创建：
+ 现状基础架构格*局和迁移后 AWS 服务 架构之间的简单总拥有成本 (TCO)***** 比较。比较结果显示了给定工作负载量的预期运行速率的差异。
+ 一个商业案例****，显示了净现值 (NPV)、投资回报率 (ROI)、投资回报期、修改后的内部收益率 (MIRR) 以及 3—5 年的现金流分析，以 AWS 包括迁移成本与保持原样。

定向商业案例的范围通常仅限于以下内容之一：
+ 基础设施技术成本比较
+ 基础架构技术和运营成本的比较

总的来说，投资组合越大，案例就越不完善。这是因为可以在不显著影响结果的情况下做出更广泛的假设。对于较小的投资组合，任何变化都会产生更大的影响，因此需要更多的细节。

首先进行基础架构成本比较。然后再决定比较是否足够引人注目，然后再继续。通常，超过400台服务器的产品组合将在运营后的3年内显示出仅基础设施成本降低的积极商业案例 AWS，或者在5年内显示出250台服务器的积极商业案例，尽管情况可能有所不同。对于较小的投资组合，可能需要更多细节。

相反，除非总迁移范围少于大约 5 个工作负载或 50 台服务器，否则在此阶段研究其他业务价值组成部分（例如从提高弹性或业务灵活性中获得的价值）几乎没有用处。

## 聚焦价值驱动因素
<a name="focus-value-drivers"></a>

基础架构技术 TCO 比较将基础设施现状成本模型与以同等性能和可用性运行工作负载所需的基本物料 AWS 服务 清单模型进行了比较。可以进行许多优化。但是，在现阶段，重点放在以下列表上，因为它们更易于评估，并且通常可以节省约30％的总拥有成本，这足以向前推进：
+ **计算弹性** — 将使用率不是 100% 的服务器（例如运行 8x5（24% 使用率）、10x5（30%）或 10x6（36%）的开发服务器或 UAT 服务器，以及运行率为 2% 的灾难恢复 (DR) 服务器，映射到仅在使用时才计费的按需服务。
+ 使用@@ **节省计划进行采购** — 计划采购使用率高（大于 36%）的生产服务器和其他服务器，并制定适当的节省计划，最多可将成本降低 75%。选项包括1年期和3年期承诺，预付款水平不同，以获得更大的折扣。
+ **移除僵尸** — 找出 CPU 利用率低于 2% 且您可以确认不再需要的服务器，并将其从成本分析中删除。
+ **计算大小合理** — 使用 CPU 和内存利用率时间序列数据来评估每台服务器所需的计算能力和内存。然后选择适合的亚马逊弹性计算云 (Amazon EC2) 实例。
+ **关系数据库管理系统 (RDBMS) 许可证大小**合适 — 在数据库服务器上进行适当调整后，重新评估您的 RDBMS 许可需求，比较自带许可证 (BYOL) 和从 AWS中获取许可证，并探索 Amazon RDatabase Service (Amazon RDS) 在增加成本方面的潜力。
+ **存储** — 适当调整所需的总存储容量，并确定整个产品组合的每秒 input/output 操作次数 (IOPS) 需求。确定可以将多少钱转移到对象存储，但费用 SLAs 各不相同。

## 数据需求
<a name="data-needs"></a>

[了解初始评估数据需求](understanding-initial-assessment-data-requirements.md)中的表格显示了构建方向性商业论证的每个部分所需的数据，以及它是必需的还是可选的。

要构建案例，您需要初始规划数据中的基础架构子集以及成本数据。确定如何确定要包括的基础架构取决于您的业务目标：
+ 如果该计划的目标是对特定应用程序进行迁移和现代化改造，则应根据应用程序的需求构建基础架构产品组合，同时考虑共享的基础架构。
+ 如果该计划的目标是以基础架构为中心，例如迁出租约即将到期的数据中心，则不需要应用程序映射来比较基础架构 TCO。

标记为可选的数据（例如服务器的 CPU 和内存峰值利用率）通常可以替换为标准基准值。您可以与 AWS 合作伙伴或 AWS 专业服务部门讨论此问题。或者，您可以从部分投资组合中可用的数据点（例如虚拟机管理程序收集的数据）中推断出值。投资组合越大，其准确性就越高。

## 建筑基础架构 TCO 比较
<a name="building-infrastructure-tco-comparisons"></a>

工具对于构建基础架构 TCO 比较至关重要。[AWS 专业服务](https://aws.amazon.com/professional-services/)或[AWS 合作伙伴](https://aws.amazon.com/migration/partner-solutions/)可以为所有类型的定向案例提供帮助，特别是如果您计划让他们参与更广泛的迁移过程。

有一些工具可用于执行以下操作：
+ 收集库存数据。
+ 收集利用率数据。
+ 提供准确的现状基础设施成本基准数据。
+ 识别并移除僵尸。
+ 进行适当规模的评估。
+ 推荐购买选项。
+ 比较软件许可选项。
+ 生成简单的图形化现金流分析。

来自的@@ [迁移评估器](https://aws.amazon.com/migration-evaluator/) AWS 是一种选择。它以**免费托管服务的形式提供所有这些功能。您可以**通过您的 AWS 客户经理或迁移能力合作伙伴或在线提交申请来[申请 AWS](https://pages.awscloud.com/Migration-Evaluator-request.html)迁移评估员。Migration Evalutor 专为单点解决方案而设计，可快速进行基础设施技术总拥有成本比较。

主要优势：
+ 免费的
+ 在限制基于工具的发现的情况下，无需代理发现或手动配置清单数据
+ 提供专门支持，以协助部署、配置、数据收集和构建基础案例或定向业务案例
+ SaaS 操作的便利性，但可以完全在客户网络中进行数据收集，以支持在加载到分析引擎之前进行清理
+ 对 Microsoft 许可证大小调整的强大支持
+ 完整的数据导出功能 

主要限制：
+ 仅评估 x86 架构服务器（Windows 和 Linux） 
+ 按原样配置或校准基准成本数据的选项有限
+ 不支持建模运营成本优化
+ 不支持迁移成本建模 
+ 除了比较 TCO 之外，没有直接支持构建业务案例

如果您决定使用商业发现工具进行投资组合发现和分析功能，例如应用程序堆栈和相互依赖关系发现，它通常还会提供基础架构总拥有成本比较。有关使用工具进行投资组合发现和评估的指导，请参阅[评估对发现工具的需求](understanding-initial-assessment-data-requirements.md#discovery-tooling)。要查看和比较市场领先工具的关键功能，请参阅[发现、规划和推荐迁移工具](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/)。

## 内置运营成本优化
<a name="building-operational-cost-optimization"></a>

IT 运营效率的提高通常是迁移的重要价值贡献者。根据国际数据公司 (IDC) 的白皮书《利用 [Amazon Web Services促进业务和组织转型以创造商业价值》，迁移到](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)后，IT运营人员的工作效率通过迁移平均提高62％。 AWS但是，在调整规模以及在定向情况下包括这些好处方面存在两个挑战。

首先，评估生产率的全面提高需要收集大量数据，而且更适合[详细的商业案例](detailed-business-case.md)。这一挑战可以通过专注于一些更容易使用简单的基准数据进行评估和定量但仍显示出显著优势的要素来解决。

其次，将生产力作为降低成本的来源可能会引起主要客户利益相关者和计划成员的担忧和消极情绪。请务必明确说明收益将如何实现，以及这对受影响的人意味着什么。通过澄清这只会增强团队的角色，可以避免此类问题：
+ 迁移计划包括培养内部运营人员并将其调到新职位的轨道，例如加入 DevSecOps 团队，构建基础架构，例如代码自动化和测试自动化，这将推动团队的发展。
+ 通过重新调整业务外包合同的范围和规模，可以实现这种好处，这样内部员工就可以更多地关注价值更高的活动

根据您要考虑的运营转型来构建此业务案例元素的方法：
+ 如果您有现有的内部运营团队，请提高团队成员的技能，并显示预期的生产力提高。
+ 或者，从您当前的运营解决方案迁移到 AWS Managed Services (AMS) 或 AWS 合作伙伴提供的替代托管服务。

对于第一次转型，为了对案例中可能包含的生产率提高进行保守的财务估计，我们建议以下几点：

1. 特别关注服务器管理运营效率。它往往占运营工作的很大一部分，可以更容易地进行评估，并且更容易在以后进行验证。

1. 根据每位全职同等学历 (FTE) 员工可以管理的服务器数量的基准，计算所需的人员配置。在本地，这个数字约为 150 台服务器。开启 AWS，大约有 400 台服务器。

1. 将这些指标应用于本地服务器数量与 EC2 实例数量的对比。

1. 将节省的时间乘以整个运营团队的混合成本费率。

然后，您可以通过验证结果是否大大超过下表中提供的按角色划分的平均工作效率提高幅度（数据来自 IDC 白皮书《通过 [Amazon Web Services 促进业务和组织转型以创造商业价值](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)》）来检查结果。

 


| ** 角色** | **效率增益** | 
| --- |--- |
| IT 基础架构管理 | 62% | 
| IT 支持 | 59% | 
| 应用程序管理 | 43% | 
| 数据库管理 | 19% | 
| 应用程序开发 | 25% | 

对于第二次转型，您可以直接将范围内产品组合的当前总运营和支持成本与正在考虑的托管服务的成本进行比较，从而增加运营成本节约。

要获得托管服务的费用，请向您的 AWS 客户经理或任何[AWS Managed Services 合作伙伴](https://aws.amazon.com/managed-services/partners/)提供您提议的物料 AWS 清单、您的服务级别选择（Plus 或 Premium）以及 AMS 套餐（AMS Accelerate 或 AMS Advanced）。这将为您提供以下方面的托管服务的总成本：转换后的解决方案的AWS 服务 组件。同样，您可以从根据自己的参数提供自己的托管服务包的 AWS 合作伙伴那里获得定价。

## 扩展到全方位的商业案例
<a name="full-directional-business-case"></a>

通常，要整理一个全方位的业务案例，请进行总体拥有成本比较，无论是否包含IT生产力要素，并估算所有迁移和现代化成本。然后创建涵盖成对t-migrate-and-modernize 情景 migrate-and-modernize的现金流。

最基本的案例是准备一对场景，其中 “不要” 场t-migrate-and-modernize 景是您当前的情况，并且该 migrate-and-modernize场景具有以下特征：
+ 交易量、计算或网络容量没有增长或萎缩
+ 存储需求稳步低量增长
+ Quality-of-service 与现有系统的能力相匹配的功能（例如可用性、耐久性、吞吐量和性能）

对于除非常小的投资组合以外的所有投资组合，这完全符合建立方向性案例的目标。它很快就证明了足够的价值，足以获得向前迈进的授权。

对于较小的投资组合，添加成对的 migrate-and-modernizet-migrate-and-modernize 场景来展示云迁移价值增加的其他方面，可能很有价值，例如：
+ 不同工作负载中等容量和高容量增长要求的组合，预计会有这种增长
+ 包括增强的弹性，例如高可用性、灾难恢复和容错能力
+ 通过边缘计算、内容分发网络 (CDN)、多区域数据库复制提高全球性能。
+ 您已将该计划列为业务优先事项的任何其他具体提高的服务质量

对于这些场景，请确保准确估算升级当前非云基础设施架构以匹配新规格所产生的成本和现金流影响。要获得此估算值，最直接的方法是向系统集成商索要报价，特别是如果他们也是具有迁移能力的 AWS 咨询合作伙伴，他们可以在两种场景中 migrate-and-modernize为您提供支持。t-migrate-and-modernize 

对于每对场景，请组装一个包含以下内容的案例：
+ “不要” t-migrate-and-modernize 情景的代价。在最基本的情况下，这包括：
  + 当前基础架构配置在业务案例期限内的总拥有成本
  + 计算、存储和网络流量消耗量定期增加 
+  migrate-and-modernize; 场景的成本，包括：
  + 设置计划，包括详细的发现、迁移规划、详细的商业案例开发、建立核心团队并提高他们的技能、如果尚未建立 landing zone，则建立一个 landing zone，以及为迁移的工作负载建立安全管理和运营集成
  + 工作负载迁移和现代化成本 
  + 迁移基础架构成本，包括网络连接、数据迁移服务（例如[AWS Snowball Edge](https://aws.amazon.com/snowball/)和）[AWS DataSync](https://aws.amazon.com/datasync/)，以及迁移过程本身所需的架构的 AWS 公用事业成本（例如，用于测试）
  + 随着浪潮的上线，在迁移过程中， AWS 公用事业成本上升，而现有基础设施被 AWS 基础服务所取代并停用，从而降低了现有基础设施的成本
+ 任何滞留资产的退役成本和注销

## 估算迁移和现代化计划设置
<a name="estimating-migration-and-modernization-program-setup"></a>

要制定成功计划，您可能需要开展一系列基础活动来建立基准能力和详细计划（如果以前没有这样做）。这些基础活动包括以下内容：

1. 执行详细的产品组合发现、迁移规划和详细的业务案例开发（如[投资组合分析和迁移规划](portfolio-analysis-migration-planning.md)部分所述），并记录所使用的任何发现工具的成本。

1. 建立云业务和技术核心团队，通过培训和招聘培养内部技能。确定需要培训的 IT 组织成员，并为每个人分配培训预算。

1. 建立 [landing zon](https://aws.amazon.com/solutions/implementations/aws-landing-zone/) e 并对其进行配置以支持所需的成本、运营和安全治理能力。

AWS 咨询合作伙伴可以帮助提供第 1 项和第 3 项的估算值。

*估算迁移和现代化成本*

为了实现方向性商业案例的目标并展示*足够的*商业潜力来进入下一阶段，请尽可能将迁移和现代化成本估算保持在基本水平。

为此，我们建议您通过重点关注属于以下迁移策略的应用程序来准备定向业务案例：
+ 停用
+ 保留
+ 重新定位
+ 重新托管
+ 更换平台
+ 回购

通常，大约 70% 的工作负载可以重新托管、重新部署或平台重建，另外 5% 的工作负载可以停用。通过迁移策略评估应用程序通常可以解决降低成本的核心问题。

**估算重构或重新架构的成本可能很复杂。**在准备定向商业论证的时间范围内尝试这样做是不切实际的。如前面在[确定迁移的 R 类型中所述，请考虑在迁移](prioritization-and-migration-strategy.md#migration-r-type)和现代化的第一阶段使用重新托管、重新定位或平台重置策略。这些 R 战略可能会在短期内加快初始投资回报，降低实施风险并改善商业案例。对于应用程序团队来说，对在环境中运行的应用程序进行现代化改造也比不在 AWS 环境中运行的应用程序容易得多。在准备好[详细的业务](detailed-business-case.md)案例时，最好添加重构（重新架构）特定应用程序的估算值。

*按策略估算迁移工作量*

每次迁移都是不同的。在提交任何预算或计划之前，请负责项目的团队（无论是内部应用程序团队、 AWS 专业服务团队还是 AWS 合作伙伴组织）对迁移活动进行工作量估算。

为了帮助建立方向性案例，下表提供了不同治疗方法的指示性工作范围。这些范围假设 medium-to-large投资组合正在迁移，并且迁移团队经过培训且经验丰富。对于小型投资组合，即使是方向性案例，也最好让负责迁移的团队准备估算值。


| 迁移策略 | 估算过程 | 元素 | 人员工时 | 人员工时 | 
| --- |--- |--- |--- |--- |
| 保留 | 什么都不做，没有成本，没有收益，也不会减少技术债务。 | – | – | – | 
| 停用 | 如果有的话，估计要停用所使用的硬件设备。 | – | – | – | 
| 重新定位 | 估计 VMware 使用 VMware 工具在其中复制工作负载。这包括复制数据、进行烟雾测试以进行验证以及任何硬件的停用。搬迁的工作量 VMs 通常比低复杂度的重新托管模式要少。 | – | – | – | 
| 重新托管 | 估计复制工作负载和数据，包括映像副本、烟雾测试、高可用性 (HA) 和灾难恢复 (DR) 测试（如适用），以及任何硬件的停用。最佳做法是使用诸如之类的工具[AWS Application Migration Service](https://aws.amazon.com/application-migration-service/)。根据数据库或其他基础架构软件是否在运行、数据库复杂性、是否集群、集成复杂性和数据量等因素，将工作负载分为低、中和高复杂度。 | 每台服务器每个应用程序的工作量 | 迁移 | HA/DR 测试 | 
| 低 | 10—14 | 3—5 | 
| 中 | 16—24 | 4—6 | 
| 高 | 26—38 | 8—12 | 
| 更换平台 | 对于包括升级操作系统或 RDBMS 版本在内的平台重构迁移，请估算重新托管的时间，并增加在新平台上运行重建和冒险测试的时间。如果重新平台包括更改平台技术，请估计使用转换工具（例如[AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/)和 [AWS Database Migration Service](https://aws.amazon.com/dms/)）以及更完整的应用程序测试所需的额外时间。技术变革的一个例子是从专有商业数据库迁移到开源替代数据库。 | 每台服务器每个应用程序的工作量 | 版本升级 | 技术变革 | 
| 低 | 添加 1—3 | 加 10—15 | 
| 中 | 添加 2—5 | 加 20—30 | 
| 高 | 加上 4—8 | 添加 40—60 | 
| 回购 | 估算数据提取、转换和上传到新购买的 SaaS 服务替代产品以及任何硬件的停用情况。 | – | – | – | 

*估算迁移基础架构成本*

包括您在迁移过程中将使用的基础设施的估算值。通常，这些估计值包括：
+ 用于连接和数据交换服务的预算，用于将工作负载和数据从当前环境迁移到 AWS
+ 在迁移、测试和切换过程中托管迁移的工作负载所需的预算 AWS 服务 （尤其是计算和存储）
+ 随着每个迁移浪潮的 AWS 完成，公用事业成本上升
+ 将不再运行迁移工作负载的现有基础架构的停用成本

对于数据交换，请检查您的总数据量并评估使用网络的可行性。如果您已在迁移后提前在 WAN 上预配置了[AWS Direct Connect](https://aws.amazon.com/directconnect/)链路或[Site-to-Site VPN](https://aws.amazon.com/vpn/)从 AWS 某一点供操作使用，则可以在不超过其服务配额的情况下使用该资源。

如果您的网络容量不足，那么使用虚拟专用网络 (VPN) 短期增加互联网带宽通常是一种极具成本效益的解决方案。否则， AWS 媒体交换设备（例如[AWS Snowball Edge](https://aws.amazon.com/snowball/)和等）在大多数情况下都[AWS Snowball Edge](https://aws.amazon.com/snowcone/)提供解决方案 AWS 区域。此外，对于容量非常大的数据迁移，可以考虑包括预算 [AWS DataSync](https://aws.amazon.com/datasync/)，这样可以提高可靠性，并且无论使用何种介质，都可以加快传输速度。

对 AWS 服务的增加和现有基础设施的缩减进行建模对于商业案例的现金流分析要素很重要。在这个阶段，你不太可能有波浪计划来确定何时会产生成本。我们建议执行下列操作：
+ 在迁移过程中，以恒定的 AWS 速度提高成本。
+ 降低您计划在相同时间内以固定费率停用的现有基础架构的成本。

在现有基础设施缩减前 1-2 个月开始增加 AWS 成本。这为每个浪潮提供了 1 个月的 AWS 公用事业使用量，以进行迁移。这包括测试时间，以及完成停用工作所需的额外时间，以停止在更换后的基础设施上产生成本。

*估算退役成本*

停用无法重新部署的设备，并以合法和环保的方式处置这些设备，可能会产生一些小额成本。但是，对于有针对性的商业案例，通常唯一潜在的重大金额是注销被替换资产任何剩余账面价值的成本。

对于方向性商业案例，我们建议您执行以下操作：
+ 查看您的资产清单。
+ 确定那些将要退役的。
+ 为了减少注销，请研究切换设备的机会，以便清单上的新设备可以用来取代较旧、折旧得更充分的资产。
+ 评估届时将退役的资产的 future 账面价值。
+ 将其作为退役的迁移成本包括在内。

*整理和调整全方位商业案例*

在为每对情景准备好全套成本后，为每种情景构建贴现现金流报表并绘制图表。我们建议在硬件更新周期的同一时期内建立有针对性的业务案例。服务器、存储设备和网络设备通常为 5 年。当您使用与硬件更新周期相同的时间段时，每种场景的按原样成本中包含一次更新的成本。

然后计算获得批准以进入该计划的下一阶段所需的关键财务指标。我们通常包括以下内容：
+ 净现值（NPV），用于衡量所评估的成本削减和生产率提高的绝对价值
+ 以月为单位的投资回报期，以验证回报是否足够快
+ 最终的运行速率比较，以验证该过程在整个期限内是否节省了足够的成本
+ 投资回报率 (ROI) 和修改后的投资回报率 (MIRR)，用于评估该计划的相对财务业绩，而不是贵组织可能优先考虑的其他资本需求

使用案例的第一次迭代来确定预期的财务业绩是否意味着应该进行改进，如以下示例所示：
+ 如果投资回报太慢，可以考虑加快迁移速度并降低迁移成本的选项，例如：
  + 使用 AWS 合作伙伴或 AWS 专业服务来扩展可用资源，并使用更基本的模式进一步并行迁移工作负载。
  + 对于正在运行的工作负载 VMware，请将迁移策略与重新托管或重定平台策略进行比较，至少在初始阶段是如此。使用迁移策略可以降低迁移成本并提高迁移速度。
  + 在技术上可行的情况下，将需要更复杂的平台重构或重构（重新架构）策略的工作负载推入未来阶段，超出最初的业务案例范围。
+ 如果 ROI 和 MIRR 太低，请考虑以下几点：
  + 你正在考虑的情景是否过于保守？ 您是否有一种情景可以反映最有可能的容量增长和弹性需求？ 您是否有方案可以比较目标中包括服务质量提高在内的成本？
  + 您能否完善要在第一阶段迁移的应用程序组合的范围，将重点放在能够带来更高回报的工作负载上，例如当前利用率较低或灾难恢复 (DR) 需求昂贵的工作负载？
  + 能否完善应用程序组合的范围，以便在最初排除商业化程度较低的特定工作负载？ 例如，由于公共云基础架构中的部署条款不同，第三方软件许可证变得更加昂贵的工作负载，您能否推迟这些工作负载？
+ 如果最终的运行速率比较未达到预期目标，请探索以下内容：
  + 首先，确认其他指标是否符合预期。方向性商业案例主要是为了表明有足够的财务机会来证明启动下一阶段的迁移准备是合理的。
  + 确定在迁移初始阶段 AWS 之后继续提高成本效益的机会清单。

在准备详细的商业论证时，包括对机会清单的评估。此外，在案例的持续维护和迁移完成后 month-to-month的成本优化流程中包括机会评估。