每個(gè)公有云廠(chǎng)商會(huì )沉淀出自己的遷移方法論，微軟的方法論云采用框架（CAF）看著(zhù)的是理論聯(lián)系實(shí)際，同時(shí)結合優(yōu)化結構框架（WAF），側重上云細節設計以及實(shí)際操作。詳情可以參考參考我們之前發(fā)布的內容：云基礎架構采用者避坑指南：擁抱“云”，更懂“云”。 本篇我們會(huì )重點(diǎn)介紹項目實(shí)施過(guò)程的前三步。

　　遷移項目始于客戶(hù)的遷移動(dòng)機，根據客戶(hù)的遷移動(dòng)機來(lái)指定遷移目標，這個(gè)目標是衡量遷移項目是否成功的基準。所以風(fēng)險分析第一步就是明確客戶(hù)遷移目標，結合客戶(hù)的現有 IT 環(huán)境來(lái)綜合評估客戶(hù)的目標是否可以完成。

　　也許在客戶(hù) IT 環(huán)境調研時(shí)發(fā)現各種復雜的技術(shù)問(wèn)題，企業(yè)級客戶(hù)系統繁多，并且復雜，來(lái)自不同時(shí)期上線(xiàn)的，使用了異構的技術(shù)架構。這些需要進(jìn)行評估能否靠一些技術(shù)方案解決。如果是繞不過(guò)去的硬傷，要及時(shí)跟客戶(hù)提出來(lái)與客戶(hù)討論解決方法。

　　客戶(hù)調研階段，我們需要對客戶(hù)的IT信息盡量做細致的了解，以提早發(fā)現可能導致遷移失敗的風(fēng)險點(diǎn)。針對客戶(hù)每個(gè)系統，提出相關(guān)問(wèn)題及拓撲圖邏輯圖信息。

　　了解了客戶(hù) IT 信息后，開(kāi)始考慮遷移方案。通常遷移方法有很多種，比如下圖中看到的Rehost,Refactor,Rearchitect,Rebuild,Replace（重新托管，重構，重新架構，重建，替換）等。這些方法從左到右，遷移后對系統的革新程度（現代化或數字化轉型）越來(lái)越顯著(zhù)，也越來(lái)越多利用到云的特性，但需要實(shí)施周期通常也會(huì )更長(cháng)，且可能帶來(lái)更大的實(shí)施風(fēng)險。所以對于大型云遷移項目中，考慮最小的風(fēng)險，最適合的方式是 Rehost（即Lift & Shift）：通過(guò)鏡像遷移的方式將系統遷移上云，從云上的基礎架構上看基本與客戶(hù)本地數據中心保持一致。這種遷移最簡(jiǎn)單，花費的時(shí)間通常也是最短。如某些系統無(wú)法通過(guò) Rehost 方式遷移的話(huà)，可以考慮 Refactor 等方式。

　　所以，總體來(lái)說(shuō)，建議優(yōu)先考慮 Rehost。遷移實(shí)施結束后，客戶(hù)可以基于云的使用階段繼續按照下圖所示架構，在云上進(jìn)行優(yōu)化。

　　確定了遷移方法，開(kāi)始考慮使用的遷移工具，從下圖列出了一些相關(guān)工具種類(lèi)，目前針對不同的遷移方法會(huì )有多種遷移工具來(lái)選擇，公有云第一方或第三方工具，功能上各有特色。選擇的原則是：使用適合自己的工具，無(wú)論第一方或第三方。

　　確定了遷移方案后，需要對遷移系統做一個(gè)遷移的技術(shù)驗證（PoC），建議使用客戶(hù) IDC 的真實(shí)環(huán)境（或客戶(hù)測試環(huán)境），基于有代表性同時(shí)對業(yè)務(wù)影響小的系統環(huán)境做遷移測試，通常 Rehost 方式也可以基于技術(shù)類(lèi)驗證，并非整個(gè)系統。在驗證中可以暴露出方案中沒(méi)有考慮到或著(zhù)隱性的一些坑，通過(guò)驗證結果能及時(shí)修改遷移方案。

　　每一個(gè)批次的應用切割切割通常需要 8-48 小時(shí)完成，關(guān)鍵注意事項可以在文末經(jīng)驗總結中查看。

　　針對不同的客戶(hù)場(chǎng)景，遇到的技術(shù)問(wèn)題不盡相同，最后，我們針對 Azure 實(shí)際遷移項目過(guò)程的實(shí)踐經(jīng)驗，總結云遷移關(guān)鍵點(diǎn)供大家參考：

　　以上的一些基于風(fēng)險評估考慮的一些信息希望能夠給實(shí)施遷移項目的架構師或工程師有所幫助，后續我會(huì )繼續從不同的一些方面總結遷移的方案和經(jīng)驗。