每个公有云厂商会沉淀出自己的迁移方法论，微软的方法论云采用框架（CAF）看着的是理论联系实际，同时结合优化结构框架（WAF），侧重上云细节设计以及实际操作。详情可以参考参考我们之前发布的内容：云基础架构采用者避坑指南：拥抱“云”，更懂“云”。 本篇我们会重点介绍项目实施过程的前三步。

　　迁移项目始于客户的迁移动机，根据客户的迁移动机来指定迁移目标，这个目标是衡量迁移项目是否成功的基准。所以风险分析第一步就是明确客户迁移目标，结合客户的现有 IT 环境来综合评估客户的目标是否可以完成。

　　也许在客户 IT 环境调研时发现各种复杂的技术问题，企业级客户系统繁多，并且复杂，来自不同时期上线的，使用了异构的技术架构。这些需要进行评估能否靠一些技术方案解决。如果是绕不过去的硬伤，要及时跟客户提出来与客户讨论解决方法。

　　客户调研阶段，我们需要对客户的IT信息尽量做细致的了解，以提早发现可能导致迁移失败的风险点。针对客户每个系统，提出相关问题及拓扑图逻辑图信息。

　　了解了客户 IT 信息后，开始考虑迁移方案。通常迁移方法有很多种，比如下图中看到的Rehost,Refactor,Rearchitect,Rebuild,Replace（重新托管，重构，重新架构，重建，替换）等。这些方法从左到右，迁移后对系统的革新程度（现代化或数字化转型）越来越显着，也越来越多利用到云的特性，但需要实施周期通常也会更长，且可能带来更大的实施风险。所以对于大型云迁移项目中，考虑最小的风险，最适合的方式是 Rehost（即Lift & Shift）：通过镜像迁移的方式将系统迁移上云，从云上的基础架构上看基本与客户本地数据中心保持一致。这种迁移最简单，花费的时间通常也是最短。如某些系统无法通过 Rehost 方式迁移的话，可以考虑 Refactor 等方式。

　　所以，总体来说，建议优先考虑 Rehost。迁移实施结束后，客户可以基于云的使用阶段继续按照下图所示架构，在云上进行优化。

　　确定了迁移方法，开始考虑使用的迁移工具，从下图列出了一些相关工具种类，目前针对不同的迁移方法会有多种迁移工具来选择，公有云第一方或第三方工具，功能上各有特色。选择的原则是：使用适合自己的工具，无论第一方或第三方。

　　确定了迁移方案后，需要对迁移系统做一个迁移的技术验证（PoC），建议使用客户 IDC 的真实环境（或客户测试环境），基于有代表性同时对业务影响小的系统环境做迁移测试，通常 Rehost 方式也可以基于技术类验证，并非整个系统。在验证中可以暴露出方案中没有考虑到或着隐性的一些坑，通过验证结果能及时修改迁移方案。

　　每一个批次的应用切割切割通常需要 8-48 小时完成，关键注意事项可以在文末经验总结中查看。

　　针对不同的客户场景，遇到的技术问题不尽相同，最后，我们针对 Azure 实际迁移项目过程的实践经验，总结云迁移关键点供大家参考：

　　以上的一些基于风险评估考虑的一些信息希望能够给实施迁移项目的架构师或工程师有所帮助，后续我会继续从不同的一些方面总结迁移的方案和经验。