本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 大型迁移的最佳实践
大型迁移可能会变得具有挑战性，这取决于决定组织运作方式的因素。本节介绍一些关键因素，如果在工作的初始阶段得到解决并在整个项目中进行跟踪，则可以简化大型迁移。
以下大型迁移的最佳做法基于从其他客户那里捕获的数据。最佳实践分为三类：
+ People
+ Technology
+ 进程
# 人员角度
本节重点介绍人员视角的以下关键领域：
+ 高管支持 — 确定有权做出决策的单线程领导者
+ 团队协作和所有权 — 不同团队之间的协作
+ 培训 — 主动培训团队掌握各种工具
## 行政支持
**Contents**
+ [确定单线程领导者](#leader)
+ [协调高级领导团队](#align-leadership)
### 确定单线程领导者
在开始大规模迁移时，重要的是要确定一位百分之百地致力于项目并负责任的单线程技术主管。该领导者有权做出决策，帮助避免孤岛，并通过保持一致的优先级来简化工作流程。
一家大型全球迁移客户能够从计划开始时的每周一台服务器扩展到第二个月初的每周80多台服务器。作为单线程领导者，首席信息官的全力支持对于正在迁移的服务器的快速扩展至关重要。首席信息官参加了每周一次的迁移切换电话会议，以确保问题的实时升级和解决，从而加快了迁移速度。
### 协调高级领导团队
在迁移的成功标准方面，各个团队之间必须保持一致。虽然迁移规划和实施可以由一个专门的小团队完成，但在定义战略和执行外围活动时会遇到挑战。这些潜在的障碍可能需要不同的 IT 部门采取行动或进行上报，包括：
+ 商业
+ 应用程序
+ Networking
+ 安全性
+ Infrastructure
+ 第三方供应商
应用程序所有者、领导层、协调以及明确上报给单线程领导者的直接行动变得非常重要。
## 团队协作和所有权
**Contents**
+ [创建跨职能云支持团队](#cross-function)
+ [提前定义核心迁移团队以外的团队和个人的要求](#define-reqs)
+ [验证迁移工作负载时是否存在许可问题](#licensing)
### 创建跨职能云支持团队
**Contents**
大型迁移项目的关键第一步是使组织能够在云端工作。为此，我们建议构建[云支持引擎](https://d1.awsstatic.com/whitepapers/cloud-enablement-engine-practical-guide.pdf) (CEE)。CEE是一个授权且负责任的团队，专注于组织为迁移到做好运营准备。 AWS CEE应该是一个跨职能的团队，包括来自基础设施、应用程序、运营和安全的代表。该团队负责以下职责：
+ 制定政策
+ 定义和实施将建立组织云运营模型的工具、流程和架构
+ 继续促进利益相关者在其所代表的所有领域保持一致
一位医疗保健客户不是从CEE开始的。但是，通过最初的试点迁移，发现了差距。在最终迁移切换日期之前，由于截止日期很严格，该团队实施了一个*迁移作战室*。在迁移交战室中，来自基础架构、安全、应用程序和业务的利益相关者可以协助解决问题。
### 提前定义核心迁移团队以外的团队和个人的要求
确定核心计划之外的团队和个人，并确定他们在迁移规划阶段的参与情况。为了促进后期阶段的迁移势头，请特别注意应用团队的参与。他们需要对应用程序的了解、诊断问题的能力以及签署转换的要求。
虽然迁移将由核心团队领导，但应用团队很可能会参与迁移计划的验证和转换期间的测试。客户通常将云迁移视为基础架构项目，而不是应用程序迁移。这可能会导致迁移期间出现问题。
我们建议在选择迁移策略时考虑应用团队所需的参与程度。例如，与改变更多应用程序格局的重构或重构策略相比，重新托管策略需要更少的应用程序团队参与。如果应用程序所有者的可用性有限，请考虑使用重新托管或重定平台，而不是使用重构、重新定位或回购策略。
### 验证迁移工作负载时是否存在许可问题
当您将企业现成产品迁移到云端时，许可可能会发生变化。您的许可协议可能侧重于您的本地资产。例如，许可证可能由 CPU 提供，也可能链接到特定的 MAC 地址。或者，许可协议可能不包括在公共云环境中托管的权利。但是，与供应商重新谈判许可可能包括较长的交货时间，这会给迁移带来硬障碍。
我们建议您在确定迁移范围后立即与您的采购或供应商管理团队合作。许可还可能影响您的目标架构和迁移模式。
## 训练
**Contents**
+ [对团队进行有关新工具和流程的培训](#tools-training)
### 对团队进行有关新工具和流程的培训
定义迁移策略后，请花时间了解迁移和目标运营模式可能需要哪些培训。在迁移过程中，您可能会使用对您的组织 AWS Database Migration Service来说是全新的工具，例如。积极培训团队可以减少迁移阶段出现的延迟。
我们建议您寻求积极的知识转移方法，以便有机会亲身体验这些工具。例如， AWS 专业服务为负责大规模迁移的三个系统集成商 (SI) AWS 合作伙伴提供了几次云迁移工厂培训课程。这确保了团队在进入迁移阶段时有基本的熟悉程度。它还有助于确定主题专家 (SMEs)，他们可以在每个 SI AWS 合作伙伴团队中担任第一线上报。
# 技术视角
技术为加快大型迁移提供了坚实的基础。例如，云迁移工厂解决方案侧重于如何为迁移提供 end-to-end自动化。本节探讨了使用技术实现所需规模和速度的一些最佳实践，这些做法与范围、策略和时间表保持一致。
首要原则是尽可能考虑自动化领域。如果您的范围内有数千台服务器，则手动执行任务可能既昂贵又耗时。
要执行迁移，通常会使用多种工具，例如：
+ Discovery
+ 迁移实施
+ 配置管理数据库 (CMDB)
+ 库存电子表格
+ 项目管理
这些工具用于迁移的不同阶段，从评估到动员再到实施。这些工具的选择取决于业务目标和时间表。
计划好迁移阶段后，下一步是确保迁移团队具备使用所需工具的技能。如果团队缺乏技能或经验，请计划有针对性的训练以提高技能组合。如果可能，请创建活动，让团队可以在安全的环境中获得迁移工具的使用经验。例如，是否有沙坑或实验室服务器可供团队迁移以体验这些工具？ 或者，将初始开发工作负载用于学习目的是否可以接受？
## 自动化、跟踪和工具集成
**Contents**
+ [自动发现迁移以缩短所需的时间](#discovery)
+ [自动执行重复性任务](#repeating)
+ [自动跟踪和报告以加快决策速度](#decision)
+ [探索可以促进迁移的工具](#tooling)
### 自动发现迁移以缩短所需的时间
大多数大型迁移计划首先要了解迁移的范围（必须迁移什么）并制定策略（如何迁移）。发现是其中的一个重要方面。捕获所需的元数据点以形成迁移策略决策树。要快速迁移工作负载，您必须识别所需的迁移元数据并将其导入到实施流程（例如迁移工厂）中。提取、转换、加载 (ETL) 迁移元数据的全自动机制大大减少了发现过程所涉及的时间和工作量。
一位客户为其迁移工厂开发了全自动数据采集流程。包含所有迁移元数据的迁移浪潮计划已在 Microsoft 的电子表格中托管和维护 SharePoint。当对源进行更改时，系统会启动一项 AWS Lambda 功能，无需人工干预即可将数据加载到迁移工厂。这种自动数据采集过程帮助客户减少了手动工作，最大限度地减少了人为错误，并加快了速度。他们能够将 1,000 多台服务器迁移到 AWS。
### 自动执行重复性任务
在迁移实施阶段，必须经常重复许多小过程。例如，使用 AWS Application Migration Service (MGN) 时，必须在迁移范围内的每台服务器上安装代理。
要实现成功进行大规模迁移所需的效率和速度，最有效的方法是建立符合您特定业务和技术要求的迁移工厂。迁移工厂提供了一个集成和编排框架，该框架使用标准化数据集来加速迁移。确定所有任务后，花时间自动执行所有可以自动执行的手动任务，这些任务可以与规范的运行手册一起自动化。
[云迁移工厂](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/welcome.html)解决方案就是一个例子。Cloud Migration Factory 旨在提供迁移自动化基础，在此基础上，您可以自动执行组织特有的各个方面。例如，您可能需要更新 CMDB 中的一个标志，以突出显示本地服务器现在可以停用。在这种情况下，您可以创建一个自动化，在迁移浪潮结束时执行此任务。Cloud Migration Factory 有一个集中的元数据存储，其中包含所有浪潮、应用程序和服务器元数据。自动化脚本可以连接到云迁移工厂，以获取该浪潮中的服务器列表并相应地执行任何操作。云迁移工厂支持[AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)。
### 自动跟踪和报告以加快决策速度
我们建议构建自动迁移报告仪表板来跟踪和报告实时数据，包括该计划的关键绩效指标 (KPIs)。迁移项目涉及整个组织的利益相关者，包括：
+ 应用团队
+ 测试人员
+ 退役小组
+ 建筑师
+ 基础设施团队
+ 领导力
为了履行其职责，这些利益相关者需要实时数据。例如，网络团队必须了解即将到来的迁移浪潮，才能了解对本地资源和之间共享连接的影响 AWS。领导团队希望了解迁移已完成的程度。拥有可靠、自动化的实时数据馈送可防止沟通不畅，并为做出决策提供依据。
一家大型医疗保健客户正在努力退出数据中心，最后期限即将到来。考虑到迁移的规模和复杂性，最初花费了大量时间来跟踪和沟通利益相关者之间的迁移状态。迁移团队后来使用 [Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/quick-bi.html) 构建了可视化数据的自动控制面板，从而大大简化了跟踪和通信，同时提高了迁移速度。
### 探索可以促进迁移的工具
为迁移选择合适的工具并不容易，尤其是在组织中以前没有人管理过大规模迁移的情况下。
我们建议花点时间选择合适的工具来支持迁移。这种探索可能涉及许可成本，但是当你考虑更广泛的计划时，它可以带来成本效益。或者，您可能会发现组织中嵌入的工具可以提供类似的结果。例如，您可能已经在您的资产中部署了应用程序性能监控工具，这些工具可以提供丰富的发现信息。
由于不熟悉，技术客户最初不愿在迁移期间运行自动发现工具。因此，SI AWS 合作伙伴必须为每个应用程序召开 510 小时的会议才能手动发现资产，包括服务器名称、操作系统版本和依赖关系。据估计，如果使用发现工具，发现工作量本可以减少1,000多小时。
## 先决条件和迁移后验证
**Contents**
+ [在迁移前阶段建造 landing zone](#landing-zone)
+ [概述必备活动](#outline)
+ [实施迁移后检查以实现持续改进](#post-checks)
### 在迁移前阶段建造 landing zone
我们建议提前构建 AWS 目标环境或 landing zone，而不是在迁移浪潮中构建目标虚拟私有云 (VPCs) 和子网。建造精心设计的着陆区是迁移的先决条件。landing zone 应包括监控、治理、操作和安全控制。
在迁移之前构建和验证 landing zone 可以最大限度地减少在新环境中运行工作负载所带来的不确定性。Landing zone 到位后，利益相关者可以专注于迁移工作负载，而不必担心在账户或 VPC 级别管理的各个方面。
### 概述必备活动
除了 landing zone 之外，在迁移之前还必须调整其他技术先决条件，尤其是交货时间较长的流程。例如，对防火墙进行必要的更改，以允许将数据从本地复制到 AWS。尽早沟通技术先决条件有助于准备和分配所需的资源。由于未满足先决条件，迁移通常会停滞不前。这不仅会影响正在进行的迁移浪潮，还可能会在问题得到修复的同时推迟所有未来迁移的日期。
一家金融服务公司打算向其进行大规模迁移 AWS，目标是腾出几个数据中心。但是，他们在本地之间可用的带宽 AWS 不足以达到他们预期的速度。不幸的是，增加带宽需要新的连接，而且交货时间为三个月。这意味着在最初的三个月中，迁移速度受到限制。
### 实施迁移后检查以实现持续改进
最后，请记住实施迁移后验证，例如运营集成、成本优化以及治理和合规性检查。迁移后验证包括评估先前迁移的工作负载，以发现应应用于未来浪潮的技术经验教训。
此外，这是实施成本控制操作的绝佳机会。例如，在迁移过程中，您可能会决定将 AWS 实例的大小与您的本地资产相匹配，以减少对性能测试的需求。现在，测试不再是数据中心关闭的关键路径，您可以使用 Amazon CloudWatch 来评估实例利用率并确定较小规模的实例是否合适。
为了说明这一阶段的重要性，一家大型技术客户正在执行大规模迁移，但最初并未包括迁移后的验证。在迁移 100 多台服务器后，他们发现 AWS Systems Manager 代理（SSM 代理）配置不正确。之前迁移的所有服务器都必须进行修复，迁移停滞不前。客户还发现实例的大小是最初估计值的五倍，因此他们在每个迁移浪潮结束时都实施了成本检查点。
# 流程视角
流程带来了一致性，但它们也会不断演变，并且容易发生变化，因为每个项目都是独一无二的。当你反复运行该过程时，你将发现差距和改进空间，这些差距和改进空间可以在你失败、学习、采用和迭代时带来巨大的好处。这些变化可以带来新的想法或创新，项目和业务可以在未来利用这些想法或创新，这为增长提供了催化剂，带来了质量和团队信心。
迁移过程可能很复杂，因为它们跨越了以前可能没有关联的技术和边界。这种视角为大型迁移的具体要求提供了流程和指导。
## 为大规模迁移做准备
以下各节概述了确保您以明确的方向开始迁移之旅所需的核心原则，并得到利益相关者的支持，这对于迁移的成功至关重要。
**Contents**
+ [定义业务驱动因素并沟通时间表、范围和策略](#bus-drivers)
+ [定义清晰的升级路径以帮助消除障碍](#escalation)
+ [尽量减少不必要的更改](#change)
+ [尽早记录 end-to-end流程](#end-to-end)
+ [记录标准迁移模式和构件](#artifacts)
+ [为迁移元数据和状态建立单一事实来源](#metadata)
### 定义业务驱动因素并沟通时间表、范围和策略
在向进行大规模迁移时 AWS，您很快就会发现有很多方法可以迁移服务器。例如，可以：
+ 使用[AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)重新托管工作负载。
+ 对您的应用程序进行容器化并将其托管在[亚马逊弹性容器服务 (Amazon ECS) 或亚马逊弹性](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) Kubernetes [服务 (Amaz](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) on EKS) 托管容器平台上。
+ 将您的工作负载重新设计为完全无服务器的应用程序。
要确定正确的迁移路径，务必从业务驱动因素向后推进。如果您的最终目标是提高业务灵活性，那么您可能会偏爱后两种模式，这两种模式涉及更高级别的转型。如果您的目标是在年底之前腾出数据中心，则可以选择重新托管工作负载，因为重新托管提供的速度很快。
大规模迁移通常涉及广泛的利益相关者，包括：
+ 应用程序所有者
+ 网络团队
+ 数据库管理员
+ 执行赞助商
关键是要确定迁移的业务驱动因素，并将该列表包含在文件中，例如迁移计划成员可以访问的项目章程。此外，还要创建与目标业务成果密切一致的关键绩效指标 (KPIs)。
例如，一位客户希望在 12 个月内迁移 2,000 台服务器，以实现撤出数据中心的目标业务成果。但是，他们的安全团队并未实现这一目标。结果是进行了数月的技术辩论，讨论是错过数据中心关闭日期，而是进一步实现应用程序现代化，还是先重新托管以实现数据中心及时关闭，然后对 AWS应用程序进行现代化改造。
### 定义清晰的升级路径以帮助消除障碍
大型云迁移计划通常涉及广泛的利益相关者。毕竟，您可能会更改已在本地托管了几十年的应用程序。每个利益相关者的优先事项相互矛盾是很常见的。
尽管所有优先事项都可能推动价值，但该计划的预算可能会有限，目标结果也可能明确。管理各种利益相关者并专注于目标业务成果可能具有挑战性。当你将其乘以迁移范围内的数百或数千个应用程序时，这一挑战就会变得更加复杂。此外，利益相关者可能会向不同的领导团队汇报，这些团队还有其他优先事项。考虑到这一点，除了清楚地记录目标业务结果外，还必须定义一个清晰的上报矩阵来帮助消除障碍。这可以节省大量时间，并有助于各团队朝着共同的目标协调一致。
证明这一点的一个例子是金融服务公司，其目标是在12个月内撤出其主数据中心。没有明确的授权或升级路径，这导致利益相关者无论时间和预算限制如何，都要制定他们想要的迁移路径。在向首席信息干事上报后，制定了明确的任务规定，并提供了要求作出必要决定的机制。
### 尽量减少不必要的更改
变化是件好事，但更多的变化意味着更多的风险。当大规模迁移的商业案例获得批准后，很可能有目标业务结果推动该计划，例如在特定日期之前腾出数据中心。虽然技术人员通常想重写所有内容以充分利用 AWS 服务，但这可能不是您的业务目标。
一位客户专注于将公司的整个网络规模基础架构迁移到为期两年。 AWS他们创建了为期两周的规则作为一种机制，以防止应用程序团队花费数月的时间重写应用程序。通过使用两周规则，当必须在多年内移动数百个应用程序时，客户能够以稳定的节奏维持长期迁移。有关更多信息，请参阅博客文章[《两周规则：在 10 天内重构云端应用程序》](https://aws.amazon.com/blogs/enterprise-strategy/the-two-week-rule-refactor-your-applications-for-the-cloud-in-10-days/)。
我们建议尽量减少任何与业务结果不一致的更改。相反，应建立机制来管理未来的项目中的这些额外更改。
### 尽早记录 end-to-end流程
在大型迁移计划的早期阶段，记录完整的迁移过程和所有权分配。本文档对于教育所有利益相关者了解迁移将如何进行以及他们的角色和职责非常重要。该文档还将帮助您了解可能发生问题的位置，并在迁移过程中提供流程的更新和迭代。
在迁移项目的开发过程中，请确保理解所有现有流程，并清楚地记录集成点和依赖关系。包括需要与外部流程所有者互动的地方，包括变更请求、服务请求、供应商支持以及网络和防火墙支持。了解流程后，我们建议在负责任、负责、咨询、知情（RACI）矩阵中记录所有权，以跟踪不同的活动。要完成该过程，请确定迁移的每个步骤所涉及的时间表，从而制定倒计时计划。倒计时计划通常从工作负载迁移切换日期和时间开始倒退。
这种记录方法对于一家跨国家用电器公司来说效果很好，该公司在不到一年的时间内 AWS 成功迁移到并退出了四个数据中心。他们有六个不同的组织团队和多个第三方参与，这带来了管理开销，导致了 back-and-forth决策和实施延迟。 AWS 专业服务团队与客户及其第三方一起确定了迁移活动的关键流程，并向各自的所有者记录了这些流程。由此产生的 RACI 矩阵得到了所有参与团队的共享和同意。使用 RACI 矩阵和升级矩阵，客户缓解了造成延误的障碍和问题。然后，他们得以提前离开数据中心。
在使用 RACI 和升级矩阵的另一个例子中，一家保险公司能够在不到 4 个月的时间内退出数据中心。客户了解并实施了责任共担模型，并遵循了详细的 RACI 矩阵来跟踪整个迁移过程中每个流程和活动的进度。因此，客户能够在实施的前12周内迁移超过350台服务器。
### 记录标准迁移模式和构件
可以把它看作是为实现创建曲奇工具。可重复使用的参考资料、文档、运行手册和模式是扩展的关键。这些记录了未来的迁移项目可以重复使用和避免的经验、学习、陷阱、问题和解决方案，从而大大加快了迁移速度。这些模式和工件也是一项投资，将有助于改善流程并指导未来的项目。
例如，一个客户正在执行为期一年的迁移，其中应用程序由三个不同的 SI AWS 合作伙伴迁移。在早期阶段，每个 AWS 合作伙伴都在使用自己的标准、操作手册和工件。这给客户团队带来了很多压力，因为同样的信息可以用不同的方式呈现给他们。在经历了这些早期的痛苦之后，客户建立了迁移中使用的所有文档和工件的中央所有权，并制定了提交建议更改的流程。这些资产包括以下内容：
+ 标准迁移流程和清单
+ 网络图样式和格式标准
+ 基于业务关键性的应用程序架构和安全标准
此外，这些文件和标准的变更每周都会发送给所有团队，并且要求每个合作伙伴确认收到并遵守任何变更。这极大地改善了迁移项目的沟通和一致性，当另一个业务部门开始进行单独的大规模迁移工作时，该团队得以采用现有的流程和文档，从而大大加快了他们的成功速度。
### 为迁移元数据和状态建立单一事实来源
在规划大规模迁移时，建立真实来源对于保持各个团队的协调一致并实现以数据为导向的决策非常重要。当你开始这个旅程时，你可能会发现许多可以使用的数据源，例如配置管理数据库 (CMDB)、应用程序性能监控工具、清单列表等。
或者，您可能会发现数据源很少，因此必须创建机制来捕获所需的数据。例如，您可能需要使用发现工具来发现技术信息，并调查 IT 领导者以获取业务信息。
将各种数据源聚合到可用于迁移的单个数据集中，这一点很重要。然后，您可以在实施期间使用单一事实来源来跟踪迁移情况。例如，您可以跟踪哪些服务器已迁移。
一家想要迁移所有工作负载的金融服务客户， AWS 专注于使用已提供的数据集规划迁移。该数据集存在关键差距，例如业务关键性和依赖性信息，因此该计划开始了发现活动。
在另一个例子中，同一行业的一家公司基于对服务器基础架构库存的 out-of-date了解，开始实施迁移浪潮。由于数据不正确，他们很快就开始看到迁移数量减少了。在这种情况下，应用程序所有者无法理解，这意味着他们无法及时找到测试人员。此外，数据与其应用程序团队已完成的停用不一致，因此服务器在运行时没有用于业务目的。
## 正在进行大规模迁移
在确定业务成果并向利益相关者传达战略之后，您可以着手规划如何将大规模迁移的范围划分为可持续的移民事件或浪潮。以下示例为制定波浪计划提供了关键指导。
**Contents**
+ [提前规划迁移浪潮，确保稳定流动](#plan-waves)
+ [将波浪实施和波浪计划作为独立的流程和团队保管](#separate)
+ [从小处着手，取得丰硕成果](#start-small)
+ [尽量减少转换窗口的数量](#cutover-numbers)
+ [快速失败、应用经验并进行迭代](#iterate)
+ [别忘了回顾展](#retrospective)
### 提前规划迁移浪潮，确保稳定流动
规划迁移是该计划最重要的阶段之一。俗话说：“如果你没有做好计划，你就会计划失败。” 随着团队对迁移情况变得更加积极主动，提前规划迁移浪潮可以使项目迅速进行。它可以帮助更轻松地扩大项目规模，并随着项目需求的增加和变得复杂而改善决策和预测。提前规划还可以提高团队适应变化的能力。
例如，一家大型金融服务客户正在制定数据中心退出计划。最初，客户按顺序规划迁移浪潮，先完成一轮迁移，然后再开始计划下一波迁移。这种方法减少了准备时间。当利益相关者得知他们的应用程序正在迁移到时 AWS，他们仍需要执行几个步骤才能开始迁移。这给该计划增加了严重的延迟。客户意识到这一点后，他们实施了以未来为重点的全面迁移规划流程，提前几个月计划了迁移浪潮。这为申请团队提供了足够的通知，让他们可以执行迁移前活动，例如通知 AWS 合作伙伴、许可分析等。然后，他们可以将这些任务从程序的关键路径中删除。
### 将波浪实施和波浪计划作为独立的流程和团队保管
当波浪规划和波浪实施团队分开时，这两个流程可以并行工作。通过沟通和协调，这可以避免因为没有足够的服务器或应用程序准备好达到预期的速度而减慢迁移速度。例如，迁移团队可能需要每周迁移 30 台服务器，但在当前浪潮中，只有 10 台服务器准备就绪。这种挑战通常是由以下原因造成的：
+ 迁移实施团队没有参与浪潮规划，在浪潮规划阶段收集的数据也不完整。在开始迁移之前，迁移实施团队必须收集更多的服务器数据。
+ 迁移实施计划在波浪计划之后立即开始，两者之间没有缓冲区。
必须提前计划波浪，并在准备和开始实施波浪之间留出缓冲区。同样重要的是要确保浪潮规划团队和迁移团队共同努力，收集正确的数据并避免返工。
### 从小处着手，取得丰硕成果
计划从小处着手，并在随后的每个波浪中提高迁移速度。最初的浪潮应该是一个少于 10 台服务器的小型应用程序。在后续浪潮中添加其他应用程序和服务器，从而提高您的全部迁移速度。优先考虑不太复杂或风险较低的应用程序，并按计划加快速度，让团队有时间适应合作和学习流程。此外，该团队可以识别并实施每个波浪的流程改进，这可以大大提高后期波浪的速度。
一位客户在一年内迁移了 1,300 多台服务器。通过试点迁移和几波较小的迁移开始，迁移团队得以确定多种方法来改善以后的迁移。例如，他们早些时候确定了新的数据中心网段。在流程的早期阶段，他们与防火墙团队合作，制定了允许与迁移工具进行通信的防火墙规则。这有助于防止在未来的浪潮中出现不必要的延迟。此外，该团队还能够开发脚本，以帮助他们在每个浪潮中实现更多发现和转换过程的自动化。从小处着手帮助团队专注于早期流程改进，并极大地增强了他们的信心。
### 尽量减少转换窗口的数量
大规模移民需要采取纪律严明的方法来推动规模。在某些领域过于灵活是大规模迁移的反模式。通过限制每周切换窗口的数量，在直接转换活动上花费的时间具有更高的价值。
例如，如果切换窗口过于灵活，则最终可能会有 20 个切换，每个切换包含五台服务器。相反，你可以有两个切换，每个 50 台服务器。由于每次转换的时间和精力相似，因此更少、更大的切换可以减轻调度的操作负担，并限制不必要的延迟。
一家大型科技公司正试图在合同到期之前迁出几个租赁的数据中心。错过到期时间将导致昂贵的短期续订条款。在迁移的早期，允许应用程序团队决定直到最后一刻的迁移时间表，包括在转换前几天出于任何原因选择退出迁移。这导致项目早期阶段出现了多次延误。通常，客户必须在最后一刻与其他应用团队协商才能填写。客户最终加强了规划纪律，但是这个早期的错误给迁移团队带来了持续的压力。总体时间表的延迟导致某些应用程序无法及时离开数据中心。
### 快速失败、应用经验并进行迭代
最初每次迁移都有陷阱。尽早失败有助于团队学习、理解瓶颈，并将吸取的教训应用于更大的浪潮。预计迁移的前几波浪潮将很缓慢，原因如下：
+ 团队成员正在适应彼此和流程。
+ 大型迁移通常涉及许多不同的工具和人员。
+ 集成、测试、失败、学习和持续改进 end-to-end流程需要时间。
在最初的几波浪潮中，问题很常见，而且是预料之中的。了解这一点并将其传达给整个组织很重要，因为有些团队可能不喜欢尝试新事物而失败。失败会使团队望而却步，成为未来迁移的障碍。确保每个人都明白最初的问题是工作的一部分，并鼓励每个人尝试失败，这是成功迁移的关键。
一家公司计划在 24-36 个月内迁移 10,000 多台服务器。为了实现这一目标，他们每月需要迁移近 300 台服务器。但是，这并不意味着他们从第一天起就迁移了 300 台服务器。前几波浪潮是学习浪潮，这样团队就可以了解事情是如何运作的，以及谁有权做什么。他们还确定了可以改善流程的集成，例如与CMDB集成，以及。 CyberArk他们利用学习浪潮来失败、改进和再次失败，从而完善了流程和自动化。6 个月后，他们每周能够迁移 120 多台服务器。
### 别忘了回顾展
这是敏捷过程的重要组成部分。这是团队沟通、调整、学习、同意和向前迈进的地方。最基本的回顾展是回顾过去，讨论发生了什么，确定哪些方面进展顺利，哪些需要改进。然后可以根据这些讨论进行改进。回顾展围绕着吸取教训的概念总结了一些形式或过程。回顾很重要，因为要实现大规模迁移成功的规模和速度，流程、工具和团队必须不断发展和改进。回顾可以在其中发挥重要作用。
传统的经验总结课程要等到计划结束后才会举行，因此这些经验教训通常不会在下一轮移民浪潮开始时得到回顾。对于大规模迁移，应将吸取的经验教训应用于下一波浪潮，并应成为浪潮规划过程的关键部分。
对于一位客户，每周举行回顾会，讨论和记录从切换中吸取的经验教训。在这些会议中，他们发现了从流程或自动化的角度来看还有精简空间的领域。这导致实施了包含特定活动、所有者和自动化脚本的倒计时时间表，以最大限度地减少转换期间的手动任务，包括验证第三方工具和安装Amazon CloudWatch 代理。
在另一家大型科技公司，该团队定期举行回顾展，以找出之前的迁移浪潮中存在的问题。这导致了流程、脚本和自动化的改进，使整个项目期间的平均迁移时间缩短了40％。
## 其他注意事项
大型移民计划必须将许多领域考虑在内。以下各节提供了有关必须考虑的其他事项的想法。
**Contents**
+ [边走边清理](#clean-up)
+ [为任何其他转换实施多个阶段](#phases)
### 边走边清理
如果迁移的成本是您预期的 10 倍，并且在关闭和清理用于迁移的资源之前，该项目才算完成，则该迁移就不算成功。这种清理应该是迁移后活动的一部分。它可确保您不会在环境中留下会增加成本的未使用的资源和服务。迁移后清理也是一种很好的安全实践，可以防止暴露您的环境的威胁和漏洞。
迁移到的两个关键结果 AWS 云 是节省成本和提高安全性。留下未使用的资源可能会破坏迁移到云的业务目的。未清理的最常见资源包括以下内容：
+ 测试数据
+ 测试数据库
+ 测试账户，包括防火墙规则、安全组和网络访问控制列表 (网络 ACL) IP 地址
+ 为测试而配置的端口
+ Amazon Elastic Block Store（Amazon EBS）卷
+ 快照
+ 复制（例如停止将数据从本地复制到 AWS）
+ 占用空间的文件（例如用于迁移的临时数据库备份）
+ 托管迁移工具的实例
举一个不良清理实践的例子，SI P AWS artners 在成功迁移后并未删除复制代理。 AWS 审计发现，已经迁移的复制服务器和 EBS 卷每月的成本为 20,000 美元。为了缓解这个问题， AWS 专业服务创建了一个自动审核流程，当陈旧的服务器还在被复制时，该流程会通知 SI AWS 合作伙伴。然后，SI AWS 合作伙伴可以对未使用和过时的实例采取行动。
对于未来的迁移，我们采用了一个流程，将迁移后的超级护理周期定义为48小时，以确保平台的顺利采用。然后，客户的基础架构团队提交了本地服务器的停用申请。据悉，停用请求获得批准后，相应浪潮的服务器将从应用程序迁移服务控制台中删除。
### 为任何其他转换实施多个阶段
在进行大规模迁移时，务必专注于核心目标，例如关闭数据中心或基础设施转型。在较小的迁移中，范围蔓延的影响可能微乎其微。但是，几天的额外工作量乘以可能的数千台服务器，可以为该程序增加大量时间。此外，额外的变更可能还需要更新支持团队的文档、流程和培训。
为了克服潜在的范围蔓延，您可以实施多阶段迁移方法。例如，如果您的目标是腾出数据中心，则第 1 阶段可能只包括 AWS 尽可能快地重新托管工作负载。重新托管工作负载后，第 2 阶段可以实施转型活动，而不会危及目标业务成果。
例如，一位客户计划在 12 个月后退出其数据中心。但是，他们的迁移包括其他转型活动，例如推出新的应用程序性能监控工具和升级操作系统。迁移范围内有 1,000 多台服务器，因此这些活动大大延迟了迁移。此外，这种方法需要在使用新工具方面进行培训。客户后来决定实施多阶段方法，最初的重点是重新托管。这提高了他们的迁移速度，降低了无法在数据中心关闭日期之前完成任务的风险。