在某些情況下，云遷移并沒有無縫發(fā)生。一些公司實際上一直在努力將其數(shù)據(jù)和運營遷移到云端。然而，經(jīng)歷過此類障礙的團隊從過去的教訓中吸取了教訓，并努力使未來的遷移更加順利。

以下是一些可以幫助您順利完成此過程的指南：

1. 首先，您需要確定架構師的角色，他將自始至終領導此遷移過程。擔任此職位的人將負責規(guī)劃和完成遷移的所有階段。重點應該是定義使流程成功和順利進行所需的重構。簡而言之，架構師必須設計遷移策略、確定公共云解決方案需求并確定遷移優(yōu)先級。

2. 在開始遷移過程之前，您還必須決定是選擇單一云環(huán)境還是多云環(huán)境。當您希望應用程序在特定的云供應商環(huán)境中運行時，遷移非常容易。開發(fā)團隊只需學習一組云 API；唯一的缺點是供應商鎖定。這是因為一旦你更新了一個應用程序使其與一個供應商合作，將它轉移到另一個供應商就變得困難了。此外，當你只與一家云供應商合作時，它也會影響你與供應商就 SLA 和成本等重要條款進行談判的權力。當您決定選擇多個云提供商時，有很多模型可供選擇。最簡單的形式是一組應用程序與一個提供商和另一組應用程序與另一個提供商。您還可以在不同的云提供商之間分發(fā)您的應用程序；所以有些公司會在一個供應商中運行部分應用程序，而在另一個供應商中運行其他部分云托管提供商。

3. 第三，選擇你想要的集成級別很重要；您可以選擇深度云集成或淺層云集成。對于后者，您可以轉移現(xiàn)場應用程序并對運行應用程序的服務器進行非常有限的更改或不進行任何更改。沒有使用任何獨特的服務，所有的應用程序更改只是為了讓這個應用程序在云端正常運行。這基本上稱為直接轉移模型，其中應用程序被完整地轉移到云端。另一方面，深度云集成是必須修改應用程序以便利用云功能發(fā)揮優(yōu)勢的地方。

4. 您還應該收集 KPI 或關鍵績效指標，它們本質上是您獲得的關于任何服務或應用程序的指標。這些可以幫助您了解應用程序或服務的表現(xiàn)如何超出您的預期。因此，最好的 KPI 會告訴你遷移的進展情況，它會告訴你應用程序中仍然存在的問題。

5. 基線是指計算應用程序現(xiàn)有或遷移前性能以確定未來或遷移后性能是否可接受的過程。它還會告訴您遷移何時結束。您可以使用此過程來診斷遷移過程中可能出現(xiàn)的問題。例如，您可以為每個 KPI 設置基準指標。當您選擇較短的基線期時，您可以快速行動，但存在無法獲得具有代表性的性能樣本的風險。當您選擇更長的基線周期時，這將很耗時，但它會提供具有代表性的數(shù)據(jù)。

6. 進行云遷移時要使用的另一個重要技巧是確定遷移組件的優(yōu)先級。因此，您必須決定是一次性遷移整個應用程序還是明智地遷移應用程序組件。為此，您必須識別服務之間的連接以查看哪些服務是相互依賴的。最好開始遷移依賴最少的服務。因此，最內(nèi)部的服務首先出現(xiàn)，然后是最外層的服務或最接近客戶的服務。

7. 另一個需要記住的有用準則是重構任何需要重構的東西。因此，在遷移這些應用程序之前，您可能需要處理一些應用程序。這將確保該應用程序可以與多個正在運行的實例一起使用以進行動態(tài)縮放。此外，您的資源使用可以利用動態(tài)云的功能。

8. 在沒有數(shù)據(jù)遷移計劃的情況下，切勿開始遷移。數(shù)據(jù)的位置對于任何應用程序的性能都非常重要。因此，當您在數(shù)據(jù)訪問方法保留在現(xiàn)場的時候將數(shù)據(jù)轉移到云端時，性能將會受到影響。遷移架構師必須參與此規(guī)劃過程。您可以選擇一種雙向同步機制，一旦您將所有客戶端移動到云中，您就可以刪除現(xiàn)場數(shù)據(jù)庫。您還可以使用 AWS 或 Azure 的云遷移服務。

9. 您還可以根據(jù)應用程序的架構和復雜性，將生產(chǎn)系統(tǒng)從本地版本切換到云版本。你可以同時做所有的事情，也可以選擇一點一點地做。因此，您可以先移動幾個客戶端，然后進行測試，看看是否一切都按計劃進行。之后，您可能會移動更多的客戶。

10. 最后，您必須檢查應用程序的資源分配。云已針對動態(tài)資源配置進行了優(yōu)化，但如果靜態(tài)分配資源，則無法享受基于云的安全解決方案的優(yōu)勢。您需要確保您的團隊有適當?shù)馁Y源分配計劃。您應該能夠在需要時擴展資源。