应用程序迁移流程

您可以使用由可重复流程组成的机制将应用程序或工作负载迁移到 AWS 云端。该机制具有不同的阶段，代表了迁移的关键里程碑。

这些阶段可以分为以下几类：

• 应用程序和产品组合发现

• 深入研究应用程序，然后在云端设计目标状态 AWS

• 通过实现设计进行@@ 构建，创建可重复使用的工件，为名为 Migration Factory 的迭代敏捷流程奠定基础

• 与深入研究期间确定的依赖项和原生 AWS 服务@@ 集成

• 通过在目标架构上执行测试并解决发现的任何差距或问题来@@ 验证构建

• 按照迁@@ 移和应用程序团队同意的明确定义的切换计划（日期、时间、任务及其各自的所有者），切换到云端的应用程序

直接转换运行手册有助于规划活动，从构建一直到直接切换，从设置先决条件到应用程序完全切换到云端。 AWS 下图突出显示了切换运行手册所涵盖的不同迁移阶段。

割接阶段

在迁移过程的切换阶段，流量将从现有端点转移到云中新部署的资源。例如，对于经典 Web 应用程序，您可以将域名系统 (DNS) 记录切换到新的终端节点。但是，如果您的应用程序有多个独立的组件和集成点，则该过程可能会变得更加复杂。您可以迁移整个堆栈、数据层或独立组件，例如微服务。其中每一个都有特定的切换策略，但对于所有这些策略来说，准备工作是关键。

在转换期间，您需要实施迁移团队和应用程序所有者同意的转换计划。应将转换通知所有应用程序利益相关者。正确规划切换阶段对于云迁移的成功至关重要。在大型企业中，部署可能很复杂，需要按特定的顺序执行步骤，以便在生产环境中正确配置环境和应用程序。如果出现任何问题，您可能会遇到计划外中断、数据丢失、未达到扩展预期以及用户体验不佳的情况。在此阶段，您应该执行用户验收测试以支持成功的直接转换。

成功切换后，监控您的应用程序仪表板并停用源环境。在停用源环境之前，请考虑以下几点：

• 业务用户成功进行了回归测试

• 应用程序的 Health

• 性能指标

我们建议尽可能自动执行您的直接转换计划。例如，使用 AWS CloudFormation 模板配置基础架构，使用自动测试脚本进行回归测试。在紧张的生产工作负载转换期间，很容易引入人为错误。

此外，还要做好失败的计划。如果迁移不成功，则应执行转换计划中概述的回滚程序。