規劃您的移轉

移轉計劃會定義將工作負載移轉至 Azure 的特定順序、時間和方法。 此計劃會將高階移轉策略轉譯為可採取動作的部署順序。 它以雲端採用計劃為基礎，解決包括工作負載優先順序、遷移排序以及資料傳輸方法等戰術決策。

必要條件：遷移採用計畫、 Azure 著陸區

評估移轉整備程度和技能

整備評估可確保您的小組具備執行移轉計劃所需的技能和支援。 此步驟會識別功能差距，並透過目標定型或外部支援加速進度。

1. 評估小組的 Azure 技能。 回顧您團隊使用 Azure 服務、移轉工具和系統切換的經驗。 此評估可協助您識別特定的知識差距，並判斷小組需要哪些訓練才能成功。

2. 視需要尋求外部專家協助。 如果您的小組缺乏雲端移轉的經驗，請引進 Microsoft或Microsoft合作夥伴。 外部專家可以驗證您的移轉策略、建議適當的工具，並協助建立實際的時程表。 此支援可降低風險並加速移轉，特別是針對複雜或大型專案。

選擇您的資料遷移路徑

數據遷移路徑是將數據從目前位置移至 Azure 的方式。 正確的路徑可確保您的數據安全地、快速且符合成本效益地傳輸。 首先，請檢查您可用的網路連線、ExpressRoute、VPN 或公用因特網，以瞭解您的選項。

1. 如果您已擁有 ExpressRoute，請使用它。 ExpressRoute 提供私人、專用的 Azure 連線，比因特網連線更快且更安全。 如果您已經有 ExpressRoute 或計劃取得它，請將此方法用於所有工作負載。 請記住，ExpressRoute 需要設定時間，而且需要數據傳輸成本。

2. 如果無法使用 ExpressRoute，請使用 VPN。 當您需要安全數據傳輸但沒有 ExpressRoute 時，請選擇 VPN。 VPN 會透過因特網對 Azure 建立加密通道，但通常比 ExpressRoute 慢。 開始之前，請確定您已在 Azure 中設定 VPN 閘道。

3. 針對大量數據使用 Azure 數據箱。 數據箱最適合使用大量數據進行離線移轉。 Microsoft寄送實體裝置以將數據複製到其中，然後將它寄回。 此選項可避免使用您的網路，但由於出貨時間最長。

4. 將公用因特網用於較不敏感的數據。 此選項適用於您的數據不需要加密，且無法使用 ExpressRoute 或資料箱。 雖然這個方法隨處可用，但最不安全，而且可能會減緩其他因特網活動的速度。

判斷移轉順序

移轉排序可藉由建立工作負載移轉的邏輯順序來降低風險並建立小組信心。 順序會決定哪些工作負載會先移動，以及相依元件如何一起移轉，以防止服務中斷。 將大型項目組合組織成遷移波段。 如需有關波浪規劃的詳細指引，請參閱 移轉波規劃。

尋找相依性

1. 先找出所有依賴性。 工作負載之間的相依性若未一起移轉，會導致服務中斷。 對應內部和外部相依性 ，以在建立移轉群組之前探索這些連線。

2. 分析相依性類型和關鍵性。 不同的相依性類型需要不同的移轉方法。 區分這些類別：

   相依性類型	Description	移轉方法
   直接相依性	元件之間需要立即通訊和低延遲。	將所有直接連線的元件移至一起，以維護效能並避免中斷。
   間接相依性	牽涉到系統之間的偶爾或非關鍵互動。	如果連線容許延遲或支援混合式使用，請一起移轉或分次移轉。
   商務相依性	取決於組織或管理關聯性。	將相關的工作負載和報告系統分組並移轉，以配合商務優先順序。

3. 依相依性關聯性將工作負載分組。 根據共享資料庫、API、驗證服務或網路連線建立群組。 這些群組會形成移轉波的基礎，並確保功能所需的所有元件一起移動。 當相依性關鍵性存在不確定性時，請將元件分組在一起。 這種保守的方法可為未來的分離提供彈性。

4. 有系統地記錄每個相依性群組。 使用一致的命名慣例，根據其相依性群組標記資產。 記錄每個組使用：

   • 組名和識別碼 - 唯一標識符和描述性名稱
   • 元件清查 - 所有基礎結構元素、應用程式和服務
   • 重大相依性 - 需要特殊處理的基本連線
   • 移轉條件約束 - 商務、技術或時間需求

5. 驗證群組完整性。 確認每個群組都包含應用程式運作所需的所有元件，包括支援負載平衡器、DNS 記錄或快取層等基礎結構。

解決分離環境操作

1. 規劃無法改變的相依性。 識別因技術或法規原因而必須保留在來源環境中的元件。 記錄其無法移動的原因、連線至其他系統的方式，以及其共享的數據。 本文件可協助您建立這些元件的策略，以順暢地與雲端系統搭配運作。

2. 將分割環境作業時間降至最低。 當元件稍後可移至雲端，但無法立即移至雲端時，請使用雲端系統記錄其聯機和數據流。 使用時程表和風險管理方法來建立明確的計劃，以減少工作負載在兩個環境中運作的時間。 請考慮延遲移轉，直到更多元件可以一起移動為止。

3. 有效地連接環境。 使用 API 閘道、消息佇列和數據同步處理等整合方法，在雲端工作負載與來源環境元件之間建立可靠的連線。 這些方法可減少延遲、改善安全性，並準備最終將剩餘元件移至雲端的方式。

優先安排工作負載以進行移轉

1. 檢閱工作負載詳細數據。 請與項目關係人合作，檢閱每個工作負載的商務和技術詳細數據。 請確定已充分瞭解停機時間或失敗影響，並符合目前的商務優先順序。 使用 移轉採用計劃 來驗證業務單位、工作負載擁有者、技術相依性和關鍵性分類等詳細數據。 這些詳細數據有助於有效地排定工作負載的優先順序和順序。

   Priority	商業價值	Effort	Description
   High	High	Low	快速成效 - 先移轉以馬上見效
   中高	High	High	策略性投資 - 謹慎規劃有足夠的資源
   中低	Low	Low	輕鬆的候選專案 - 填補主要移轉之間的空白
   Low	Low	High	避免或延遲 - 將資源專注在更高價值的機會上

2. 從更簡單的工作負載開始，以降低風險。 開始移轉較不複雜且風險較低的工作負載。 這種方法可協助小組在處理更具挑戰性的工作負載之前，獲得信心並精簡移轉程式。 以具有獨立架構和最小整合點的內部工具、開發環境或低使用量應用程式為目標。

3. 請先移動非生產環境，再移動生產環境。 非生產環境提供安全的空間來測試完整的遷移過程。 在生產環境之前移轉開發、預備和 QA 環境，以驗證整備程度。 此順序可讓小組測試設定、效能和復原程式，而不會影響使用者。 使用非生產移轉來訓練營運小組。

4. 在您示範初始成功之後排程重要系統。 重要應用程式需要經過證實的移轉功能，才能將它們移至 Azure。 當您的團隊顯示出使用 Azure 服務的熟練度時，請規劃這些移轉，以便在後續階段執行。 硬體重新整理週期等商務期限可能需要您稍早使用更多保護措施和延長測試週期來排定關鍵應用程式的優先順序。

5. 包含代表性的複雜工作負載來測試情境。 將一或兩個複雜的工作負載新增至每個早期浪潮，以公開您面對的任務關鍵性應用程式的挑戰。 選擇代表常見模式的工作負載，例如多層式應用程式或資料庫相依系統。

建立詳細的移轉排程

1. 設定每個移轉的開始和結束日期。 包含測試和問題解決的緩衝區時間，以確保順暢執行。 此詳細排程可降低延遲的風險，並支援有效的資源規劃。

2. 對齊時間軸與商務事件。 避免在重要的商務期間排程移轉，例如財務關閉、產品推出或假日季節。 此一致性可降低業務中斷的風險，並確保項目關係人有信心。

3. 使用專案管理工具來追蹤進度。 使用 Azure DevOps 之類的工具來管理相依性、追蹤里程碑，以及有效地溝通變更。 這些工具提供移轉進度的可見度，並支持主動式問題解決。

為每個工作負載選擇移轉方法

移轉方法分為兩個類別：停機時間移轉，以及幾乎零停機的移轉。 根據工作負載的停機時間容錯和業務關鍵性，為每個工作負載選擇最佳的移轉方法。

1. 針對容許計劃性中斷的工作負載，選擇在停機期間進行移轉。 停機時間移轉較簡單且更快，因為它不需要來源和目標環境之間的即時同步處理。 此方法適用於具有排程維護時段的非關鍵工作負載，例如開發環境、測試系統或應用程式。 記錄每個工作負載可接受的停機時間，並在低使用量期間排程移轉，以將商務影響降到最低。

2. 針對關鍵工作負載選擇接近零停機時間移轉。 近乎零停機時間的移轉可確保在利用連續資料複寫和切換技術進行轉換期間，關鍵工作負載仍可持續運作。 對於具有嚴格服務等級協議的客戶對應應用程式、即時交易系統或工作負載而言，此方法至關重要。 驗證工作負載架構是否支援連續複寫，而且網路頻寬可以處理實時數據傳輸。 在非生產環境中測試連線和複寫程式，以確認此移轉方法的整備程度。

定義回退計劃

復原計劃可讓小組在部署失敗或帶來風險時快速回復變更。 妥善定義的計劃可將停機時間降到最低、限制業務影響，以及維護系統可靠性。 在起始任何移轉或部署之前，請一律建立復原準則和程式。

1. 定義失敗的部署。 與商務項目關係人、工作負載擁有者和作業小組共同作業，以決定哪些專案是失敗的部署。 範例包括失敗的健康情況檢查、效能不佳、安全性問題或未達到成功計量。 此定義可確保復原決策符合貴組織的風險承受能力。 在部署計劃中包含觸發復原的特定條件，例如 CPU 使用量限制、回應時間閾值或錯誤率。 此評估在事件期間能夠清楚且一致地做出回復決策。

2. 自動化 CI/CD 管線中的回滾步驟。 使用 Azure Pipelines 或 GitHub Actions 之類的工具，將復原程序自動化。 例如，若健康檢查未通過，請設定管線以重新部署先前版本。

3. 建立工作負載特定的回復指示。 開發符合工作負載類型、環境和部署方法的復原步驟。 例如，基礎結構即程序代碼部署需要重新套用先前的範本。 應用程式復原牽涉到重新部署先前的容器映像。 將復原腳本、設定快照集和基礎結構即程式代碼範本附加至復原方案。 這些資產可快速執行，並減少對手動介入的依賴性。

4. 測試回滾程序。 模擬生產階段前環境中的部署失敗，以驗證復原效率。 識別並解決自動化、許可權或相依性的差距。 確認回復會將系統還原到穩定且已知的良好狀態。

5. 改善回滾策略 在每次部署或回滾事件之後，進行回顧以評估哪些有效，哪些無效。 根據經驗教訓、架構變更或新工具，更新回滾準則、程序和自動化。 維護文件，以確保回復策略保持最新且有效。

與利害關係人協商遷移計劃

項目關係人核准會驗證您的移轉方案符合商務需求和風險承受能力。 在執行移轉之前，您應該先獲得正式核准。

1. 以業務理由記錄移轉計劃。 建立結構化計劃，其中顯示工作負載名稱、擁有者、關鍵性、移轉方法、停機時間窗口和業務效果。 包含每個方法的理由，並說明其如何將風險降到最低。

2. 提供經過測試的回滾程序。 顯示包含步驟、時間範圍和成功標準的特定還原計劃。 包含自動化和手動功能。 文件生產前測試結果，以證明快速服務還原。

3. 根據業務限制驗證排程。 審核利害關係人的時間安排，以避免關鍵的業務期間、維護凍結和季節性高峰。 如果衝突存在，請提供替代選項與取捨。

4. 取得正式核准和回復權限。 取得利害關係人對於移轉計劃和回復程序的書面核准。 定義決策授權機構，並建立緊急通信通道。

5. 定義成功準則並檢閱檢查點。 設定可測量的計量，包括效能評定、功能驗證和用戶驗收準則。 安排正式檢討會議以進行是否通過的決策。

後續步驟