概念：

企业从传统的平台向云平台的迁移，目前云迁移主要有：

  • 物理机到虚拟机(P2V)
  • 虚拟机到虚拟机（V2V）
  • 云环境向另一个云环境

AWS 云迁移：https://aws.amazon.com/cn/cloud-migration

企业为什么上云：

  • 节省了 IT 成本
  • 提高生产效率
  • 提高业务敏捷性
  • 提高运营弹性

云迁移的四个阶段：

从云迁移方法论上看，目前普遍采用的都是四阶段的迁移流程，包括：

  • 现状调研
  • 方案设计
  • 迁移实施
  • 运维优化

四个阶段相互关联，不可分离，每个阶段都是保障最终业务上云迁移的关键！

AWS的6R迁移策略：

https://aws.amazon.com/cn/blogs/china/6-strategies-for-migrating-applications-to-the-cloud

1. Re-Host (重新托管)，也称为 “简单地搬运” — 迁移复杂度：中
直接迁移是应用进行云迁移时最常见的方法，即对应用程序运行环境不做改变的情况下迁移上云， 一般的操作是 P2V（Physical to Virtual，物理机迁移至虚拟机）、V2V（Virtual to Virtual，虚拟机迁移至虚拟机）。在企业期望快速上云或大型应用上云的场景中，这种策略比较合适。

2. Re-Platform( 更换平台)，也称为 “修补再搬运” — 迁移复杂度：高
在迁移上云时，在不改变应用核心架构的基础上，对应用程序做些简单的云优化。例如将关系型数据库替换成云服务商提供的数据库服务、将自建消息中间件替换成云服务提供的消息队列服务、将 HAProxy 更换成云服务商提供的负载均衡服务，以此来降低部分管理成本提升效率。

3. Re-Purchase(重新购置)，也称为 “放弃后购买” —迁移复杂度：中
是指放弃使用原先的产品，改为采购新的替代产品，例如原先企业采用传统软件许可模式的人力资源管理系统，将放弃并选用同类 SaaS 产品来进行替换，抑或是选用了该厂商的 SaaS 版本。

4. Re-Architect (重构/重新构建)，重新设想如何构建和开发应用程序 (通常使用云原生功能) —迁移复杂度：高
改变应用的架构和开发模式，进行云原生的应用服务实现，例如单体应用向微服务架构改造，这种策略一般是在现有应用环境下难以满足日后功能、性能或规模上的需求时采用，该策略的迁移成本最高，但是长远来看会更为满足未来的需求。

5. Retire (停用，丢弃) —迁移复杂度：低
确定不再使用当前的基础设施，表明这部分系统或应用已经没有使用价值且还在持续消息资源，应该进行必要的归档备份后停用。

6. Retain (保留)， 这通常意味着“重新访问”或什么都不做 (就目前而言) —迁移复杂度：低
在部分应用或者业务未做好上云准备，或是更为适合本地部署时， 保留现状，不强行进行迁移上云操作。应用迁移应该有优先级设定，根据业务发展实际需要来进行操作。

AWS的云迁移的21个最佳实践：

https://aws.amazon.com/cn/blogs/china/21-best-practices-of-migration-to-cloud

迁移前阶段：

1. 为未来IT和业务交集的部分，制定一个清晰的愿景。
2. 规划并分享一个云治理模型。
3. 在此过程中，尽早的培训员工。
4. 花时间和精力规划AWS之上的运维管理。
5. 了解当前拥有的IT资产，以及每批迁移中都包含哪些资产。
6. 为迁移之旅选择合适的合作伙伴。

迁移阶段：

7. 从较小的和简单的开始。
8. 自动化。
9. 把云当作转型
10. 在可能的情况下，更多的运用全托管服务。

迁移后阶段：

11. 全面监控。
12. 使用云原生的监控工具。
13. 采用AWS企业支持服务。

大规模迁移（一次性迁移数百个应用）：

14. 建立一个以迁移活动为中心，由团队、工具和流程组成的健壮的迁移工厂。
15. 提供领导力以及设定迁移工厂的相关标准。
16. 在整体项目开始后，制定一个新团队成员加入流程。
17. 明智的将有天赋的专家分布于敏捷批次团队。
18. 当为一个特殊应用决定迁移策略时，考虑不同的标准。
19. 找到模式并设计蓝图。
20. 应用测试。
21. 确保将充分交流的文化灌输给所有相关团队。