本文說明如何規劃遷移波。
您可以將遷移候選項目分組，形成遷移波。您可以根據探索和評估階段收集的資訊，在高層級 (以類別為準) 或詳細層級 (應用程式、位置、元件) 進行分組。
建立應用程式目錄
如要開始規劃，請建立應用程式目錄。根據應用程式架構、業務考量和 IT 作業，將應用程式歸類。以便根據業務重要性、複雜度和遷移至雲端的風險，決定應用程式的優先順序。這些因素的組合和優先順序會因機構、業務要務，以及這些要務與工作負載的對應關係而異，無論是在目前的架構還是未來的Google Cloud 架構中，都是如此。
以下列出三大類別，以及各類別中需要考量的因素。
應用程式架構
- 技術限制
- 依附元件數量
- 層數
- 有狀態與無狀態
- 效能需求
- 地理位置依附元件
業務考量
- 法規遵循規定
- 業務重要性
- 業務變更功能
- 使用者人數
- 使用者類型 (內部、外部)
- 總持有成本
IT 作業
- 作業環境
- 服務水準協議
- 可用性
- 備份
繪製地圖並設定優先順序
從應用程式目錄中，根據複雜度和目標遷移方法繪製應用程式地圖。遷移方法應根據預期業務成果、遷移工作量，以及遷移期間和遷移後相關的風險因素而定。
然後根據業務價值和遷移所需的工作量，依優先順序排列遷移候選項目。準備遷移作業時，您可以找出功能適合先遷移的應用程式。您可以選擇一個應用程式，或在首批遷移的清單中加入多個應用程式。先遷移首批應用程式，讓您的團隊在雲端環境中測試部署作業，以便他們專注於遷移作業，而不是處理複雜的應用程式。
建議從獨立應用程式開始，這樣有助降低初始風險，等團隊有了經驗之後就可以進一步應用學到的新知識，來遷移其他更複雜且有許多依附元件的應用程式。
第一波遷移的應用程式通常並非業務關鍵，且系統和網路間的依附元件較少。此外，這類應用程式通常不需要重構，資料重力較小，沒有特定的法規遵循問題，且可負擔轉換期。詳情請參閱如何選擇要先遷移的應用程式。
分批處理應用程式
將應用程式分組為多個階段，每個階段都有相關時間表，以及根據每個階段的回饋修訂計畫的時間。
- 第 1 波：業務價值高，實作難度低。
- 這些應用程式非常適合用於早期遷移或概念驗證。
- 第 2 波：商業價值高，但實作難度高。
- 這些申請可能會優先處理。
- 第 3 波：業務價值低，但實作難度低。
- 這些申請可能會優先處理。
- 第 4 波：業務價值低，但實作難度高。
- 這類應用程式應優先處理。
定義遷移波後，您可以在專案計畫中整理這些波。
遵循最佳做法
如要改善遷移計畫，請按照驗證遷移計畫的最佳做法操作。遵循該文件中的概念，並無法保證一定能成功。不過，這份文件著重說明規劃遷移作業時經常會忽略的幾點，例如：
- 確保遷移計畫的每個步驟都有復原策略。
- 規劃漸進式推出和部署作業，如本文稍早所述。
- 提醒負責遷移工作負載的所有開發和營運團隊。
- 從目標正式環境中移除概念驗證資源和實驗。
- 定義安全淘汰來源環境的條件。
- 確保您為每個遷移階段進行遷移風險評估，並針對發現的風險執行因應措施。
後續步驟
- 瞭解如何執行遷移作業。