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