本文提供指引，協助決策者制定 Azure VMware 解決方案 的遷移策略，包括規劃、執行及退役階段。
Azure VMware 解決方案 提供結構化路徑，讓基於 VMware 的工作負載以最小化應用程式變更遷移至 Azure。 成功不僅取決於遷移虛擬機。 組織需要明確的遷移政策、工作負載評估標準、驗證標準及執行控管，以降低風險、維持營運連續性，並支持長期平台目標。
推薦：在遷移至 Azure VMware 解決方案 前，先定義您的遷移策略、工作負載評估方法、遷移順序及驗證需求。
1. 移民規劃
在設計任何東西之前，先清楚規劃要遷移哪些內容、順序是什麼，以及為什麼要遷移。 使用 雲端採用架構 Plan 方法來評估您的遺產。 Azure VMware 解決方案 最適合重架方式，只需最小的干擾，且短期內無需現代化。 它並不是每個應用程式都適合的環境，而是否適用，則是在規劃階段決定的。
1.1 發現與清點
Azure Migrate 會掃描你本地的 vSphere 環境，並建立虛擬機、資源使用情況及相依性清單。 這些資料會影響大小（主機數量及主機類型）及波次規劃（哪些工作負載會一起移動）。 Azure Migrate 不會執行移到 Azure VMware 解決方案 的操作。 它提供證據來評估和排序專案。
1.2 移民策略
Azure VMware 解決方案 主要支援重新託管的方法。 需要重構或重新架構處理的應用程式，可能更適合使用 Azure 原生運算。 記錄這些決策，讓計畫反映出深思熟慮的選擇，而非違約。 請參閱 「選擇雲端遷移策略」。
1.3 工作量評估
並非所有工作負載都同樣適合 Azure VMware 解決方案。 在將工作負載分配給遷移波之前，先評估其技術需求、營運依賴性及平台契合度。 結構化評估能幫助您及早識別風險、驗證適用性，並確保遷移計畫反映企業優先事項而非假設。
1.3.1 需求
在將工作負載指派到遷移浪潮前，先評估影響其在 Azure VMware 解決方案 上成功的技術、營運及業務需求。 此評估有助於您判斷平台適用性、識別潛在遷移挑戰，並提供規模、排序及準備度決策所需的資訊。 評估每項工作量時，請聚焦於：
性能要求： 了解 CPU、記憶體、儲存 IOPS 以及網路吞吐量的需求。 將這些需求對應至 Azure VMware 解決方案 主機 SKU 與 vSAN 儲存政策，包括 RAID 配置及容忍失敗（FTT）設定。
應用程式相依性： 辨識每個工作負載與哪些系統通訊。 相依關係決定了你的遷移波規劃，以及相依系統是否需要一起移動。
相容性要求：確認 Azure VMware 解決方案 是否支援客用作業系統和第三方軟體。 大多數在本地 vSphere 上運行的工作負載，都是在 Azure VMware 解決方案 上運行，無需修改，但會進行驗證而非假設，並確保你測試回滾策略以防有問題的遷移。
網路需求： 記錄每個工作負載所需的網路區段、IP 位址、DNS 設定及防火牆規則。 識別對延遲敏感的工作負載，並確保網路架構能因應其需求而優化。
1.3.2 工作量處理
工作負載評估可識別工作負載所需的項目。 工作量處理決定了該採取的行動。 決策者應評估每個應用程式是否適合使用 Azure VMware 解決方案、是否應留在本地，或是部分應用程式更適合由 Azure 原生服務提供。 針對每個工作量，請確定：
工作量是否應該放在那。 已經能在 vSphere 上良好執行的工作負載，是很自然的候選對象，尤其是那些短期內沒有現代化規劃的工作負載。 對於即將退休或取代 SaaS 的工作流程，請權衡搬遷是否能帶來價值，或是應該一直保留到生命週期結束。
是否每個層級都應該屬於那裡。 一個工作負載通常包含多個層級，例如網頁前端和資料庫。 你可以在 Azure VMware 解決方案 上執行應用程式虛擬機，並將它們連接到 Azure 原生的資料服務，例如 Azure SQL Database。 這種配置讓你除了管理 VMware 工作負載外，也能享有管理式資料庫的優勢，並降低 VMware 主機和授權的成本。
1.4 移民準備
定義每個工作負載在批准生產環境使用前必須符合的最低操作、效能、安全與治理要求。
在每一波遷移中都套用一致的驗證框架。 該框架應定義必要的檢查、核准準則，以及團隊在獲得切換核准前必須提供的證據。 至少，請驗證：
HCX 複寫健全狀況
NSX 網段可路由性
ESXi 宿主健康狀況
來自目標區段的身份與認證可達性
支援服務（例如備份和監控）的健康狀況
決定團隊是否必須在遷移前從來源環境擷取基線效能指標。 這些測量為驗證遷移後表現及識別迴歸提供了參考點。
切換前，要求團隊判斷外部 DNS 紀錄、負載平衡器設定、應用程式端點或其他連線依賴是否需要更新。 將所有必要的變更納入波段切換計畫，以降低服務中斷的風險。
1.5 Azure VMware 解決方案 遷移序列
遷移順序決定哪些工作負載先、第二、依此類推移到 Azure VMware 解決方案。 良好的波浪規劃能降低風險並避免不必要的干擾。
依依賴性分類： 利用發現中的相依資料尋找密切合作的虛擬機集合，例如應用程式伺服器及其資料庫。 把它們放在同一波次，這樣當其中一個部分還在本地等待時，流量就不會每次都穿越網路。
盤點現有規則： 記錄內部部署環境中的任何親和性或反親和性規則，並規劃如何重新建立這些規則。 Azure VMware 解決方案 的部署政策強制虛擬機與主機的親和性，這對於授權限制（如 SQL Server）及嚴格的效能需求非常重要。
依風險排序： 從風險較低的工作負載開始，例如非生產系統或依賴較少的應用程式。 在流程承擔業務關鍵型應用程式之前，你的團隊會先對這個流程建立信心。 隨著經驗累積，轉向複雜度更高的工作負載。
與網路延伸計畫對齊： 根據你本地的網路配置來規劃你的序列。 當多個應用程式共用網路區段時，請在同一波或連續波次中遷移它們。 接著你可以立即將該段切換到支援 Azure VMware 解決方案 的原生網路，並移除臨時擴充功能。
1.6 遷移工具
使用 VMware HCX 將工作負載移至 Azure VMware 解決方案，且中斷最小。 HCX Enterprise 無須額外費用，並預設安裝，可啟用例如 Replication Assisted vMotion 和 Mobility Optimized Networking 等功能。 你不需要使用 HCX，也可以透過 合作夥伴遷移方案引入實體工作負載。
1.6.1 遷移方法
vMotion 能在沒有停機的情況下移動一個正在運行的工作負載，在第二代中通常比批量方法執行得更快。 目前，在 Generation 2 上，複寫輔助遷移和大量遷移的執行速度可能較慢，因此請規劃較長的作業時段，並據此安排各波次的時程。 請參閱 Azure VMware 解決方案 第二代私有雲設計考量。
1.6.2 網路擴展治理
有些團隊將網路延伸視為永久設計。 不是。 只在遷移期間開啟擴充功能。 HCX 網路擴充將本地網路延伸至 Azure VMware 解決方案 的第二層，讓工作負載在遷移過程中保留現有位址。 此設計可避免事先重新配置應用程式，但也伴隨一些必須由決策者加以管控的取捨。
內部部署相依性。 延伸網路通常會將其閘道器保留在內部部署環境中，因此工作負載即使在移轉之後，仍然依賴來源站台。
路由效率低下。 流量可能會先回到內部部署環境，再返回原路徑；這種稱為 tromboning 的模式會增加延遲和故障點。
訂立明確的政策。 只有當工作負載無法更改位址時才擴展網路，且當工作負載移動後移除所有擴展。 先評估你的本地網路狀況，這樣你才能知道哪些區段需要延伸以及延長多久。 該評估會作為你的波次規劃和延伸時程的依據。 行動優化網路在特定情況下可以減少長號聲，因此啟用前請確認支援的設定。 請參閱配置 HCX 網路擴充。
2. 遷徙準備
以下部署順序反映了各階段之間的依賴關係。 每個步驟都假設前一個步驟已完成且已驗證。
月台降落區：確保所有必要的集中式網路、身份、安全與監控服務都已準備好與 Azure VMware 工作負載整合。 透過 Azure 原則 將治理與安全基準套用到管理群組階層，幫助你達成合規要求。 第二代部署到你的虛擬網路中，因此對網路安全群組或路由表施加嚴格規則的政策基線可以阻擋部署。 部署前先從私有雲的虛擬網路移除這些特定政策，之後再重新套用。 將此例外納入你的基準，避免治理阻礙推展。
工作負載登陸區： 將您的工作負載登陸區（訂閱）放置在正確的管理群組之下，無論是線上或內部（「Corp」）。
IP 位址範圍： 為私有雲保留至少一個 /22 位址區塊。 在第 2 代環境中，也請另外預留兩個額外的 /24 區塊，供 HCX 管理和上行連線使用。 確認這些範圍沒有與你的本地、Azure 或其他雲端位址空間重疊。 部署後很難輕易修正這種狀況。 請參閱 第二代設計考量。
配額申請： 請盡早申請配額，因為分配可能長達五個工作天。 申請足夠的資源以因應成長與災難復原需求，例如 N+1 備援，也就是比工作負載所需多一部主機。 確認新部署所需的可攜式 VMware Cloud Foundation 授權。 請參見 「請求主機配額」。
Azure VMware 解決方案 私有雲部署：將第二代私有雲配置至其 Azure 虛擬網路中。 請參見 「建立第二代私有雲」。
網路與身份設定： 將私有雲網路對等到你的樞紐，建立本地連線。 將 vCenter Server 連接到你的外部身份來源，讓管理員用受管理帳號登入，而不是共用內建憑證。
監控與管理： 將日誌轉發至您的日誌管理解決方案，並設定服務健康警示。 透過 Azure Arc 安裝訪客虛擬機，這樣你就能用和其他地方用的 Azure 工具來管理它們。
HCX 安裝： 在開始第一波測試前，先安裝HCX並測試站點間連線。
3. 遷移執行
在每一波之前，請定義「完成」是什麼意思。 當工作負載已通過驗證、網路延伸已移除，且應用程式在其永久狀態下維持正常時，該波次即告完成。
在每波前定義回滾標準，並在遷移生產系統前測試回滾路徑。 HCX 支援反向遷移，具體方法取決於你使用的遷移類型。 Wave 成功標準包括：
Wave 中的每台虛擬機都運行在 Azure VMware 解決方案 上，不再依賴網路擴充來處理生產流量。
每個應用程式都能被使用者及其相依系統存取。
每台虛擬機器都會出現在你的監控工具中，沒有任何警告或錯誤。
回滾不再需要，你可以正式關閉它。
應用程式效能與基準相當甚至超越。
這些工作負載符合您的安全與合規要求。
工作負載已成功納入備份與災難復原解決方案。
4. 移轉評估與淘汰
遷移不會在 Azure VMware 解決方案 工作負載啟動時結束。 驗證工作負載在新環境中能正常運作，確認已移除臨時遷移因應措施，並正式汰除來源端基礎設施。 保留您現有的內部部署基礎架構，可能會導致產生未被發現且未被記錄的相依關係。 嚴謹的評估與退役流程確保組織實現遷移帶來的預期效益，且不承擔不必要的營運成本或風險。
4.1 切換後生產準備
制定並強制執行切換後的驗證準則，以確認工作負載的運作符合預期。 檢查網路可達性和名稱解析。 檢查應用程式功能及與相關系統的通訊。 每台虛擬機移動後，確認其啟動、資源是否符合計畫，以及正確的儲存政策是否適用。 將表現與遷移前基線做比較。
決定你的平等政策。 關鍵決策是遷移後的工作負載是否必須達到與本地狀態完全一致，才能稱為生產準備，還是允許暫時的偏差。 許多組織要求面向客戶的系統立即達到效能均衡，但卻給予內部應用程式短暫的穩定期，並有固定的修復期限。
4.2 連通性驗證
驗證 Azure VMware 解決方案、Azure、內部部署環境、網際網路及名稱解析之間的端對端連線能力。 執行應用程式煙霧測試，確認工作負載是否達到其目的。 確認外部名稱記錄或負載平衡器設定是否需要更新，作為切換的一部分。
如果你建立了 Azure VMware 解決方案 的次要實例用於災難復原，請確保它能同時從主實例以及任何需要連線的客戶端或支援服務（如果啟用時）都能存取。
4.3 網路擴充功能解除
當延伸區段上的所有工作負載都已移轉後，請移除 HCX 第 2 層延伸，並確認 Azure VMware 解決方案 原生閘道器可正確路由。 不要讓延長期限超過遷移所需的時間。
4.4 停用來源環境
停用會正式釋出來源端容量、授權及營運涵蓋範圍。 把它當作有規範的交接，而不是清理任務。 如果你跳過退役，你就得為閒置的基礎設施付出代價，並承擔安全風險。 使用 將工作負載移轉至雲端後淘汰來源端工作負載 來設定作業順序、來源端備份的保留期限、關閉來源端系統所需的核准程序，以及回收授權與硬體的標準。
下一步
工作量設計：