本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 大型遷移的最佳實務
大型遷移可能會變得具有挑戰性，取決於管理組織運作方式的因素。本節涵蓋一些關鍵因素，如果在努力的初始階段處理並在整個專案中追蹤，可以簡化大型遷移。
下列大型遷移的最佳實務是根據從其他客戶擷取的資料。最佳實務分為三個類別：
+ 人物
+ 技術
+ Processes
# 人員觀點
本節著重於人員觀點的下列關鍵領域：
+ 執行支援 – 識別有權做出決策的單執行緒領導者
+ 團隊協作和擁有權 – 在不同團隊之間協作
+ 訓練 – 在各種工具上主動訓練團隊
## 執行支援
**Contents**
+ [識別單一執行緒領導者](#leader)
+ [協調資深領導團隊](#align-leadership)
### 識別單一執行緒領導者
開始大型遷移時，請務必識別 100% 致力於專案並負責的單一執行緒技術領導者。該領導者有權透過維持一致的優先順序來做出決策、協助避免孤立，以及簡化工作流程。
大型遷移全球客戶能夠在程式開始時每週從一個伺服器擴展到第二個月開始時每週超過 80 個伺服器。CIO 作為單執行緒領導者的完整支援對於快速擴展要遷移的伺服器至關重要。CIO 每週與遷移團隊進行遷移切換呼叫，以確保問題的即時升級和解決，從而加速遷移速度。
### 協調資深領導團隊
請務必在各種團隊之間建立遷移成功條件的一致性。雖然遷移規劃和實作可以由小型的專用團隊完成，但在定義策略和執行周邊活動時會產生挑戰。這些潛在障礙可能需要 IT 組織不同領域的動作或呈報，包括下列項目：
+ 商業
+ 應用程式
+ 聯網
+ 安全
+ 基礎設施
+ 第三方供應商
應用程式擁有者、領導階層、一致性和明確呈報至單一執行緒領導者的直接動作變得很重要。
## 團隊協作和擁有權
**Contents**
+ [建立跨職能雲端啟用團隊](#cross-function)
+ [事先定義核心遷移團隊以外的團隊和個人需求](#define-reqs)
+ [驗證遷移工作負載時沒有授權問題](#licensing)
### 建立跨職能雲端啟用團隊
**Contents**
大型遷移專案中的關鍵第一步是讓組織能夠在雲端中運作。為了達成此目的，我們建議您建置[雲端啟用引擎](https://d1.awsstatic.com/whitepapers/cloud-enablement-engine-practical-guide.pdf) (CEE)。CEE 是強大且負責的團隊，專注於組織遷移至 的操作準備程度 AWS。CEE 應該是一個跨職能團隊，其中包含來自基礎設施、應用程式、操作和安全性的表示法。團隊需承擔下列責任：
+ 制定政策
+ 定義和實作將建立組織雲端操作模型的工具、程序和架構
+ 繼續促進利益相關者在其代表的所有領域之間的一致性
一位醫療保健客戶沒有從 CEE 開始。不過，透過初始試行遷移，發現了差距。在最後遷移切換日期之前，團隊實作了*遷移戰室*，並設定了嚴格的截止日期。在遷移戰室中，來自基礎設施、安全、應用程式和業務的利益相關者可協助解決問題。
### 事先定義核心遷移團隊以外的團隊和個人需求
識別核心計畫之外的團隊和個人，並定義他們在遷移規劃階段的參與。為了在稍後階段促進遷移的動能，請特別注意應用程式團隊的參與。他們必須具備應用程式的知識、診斷問題的能力，以及要求簽署切換。
雖然遷移將由核心團隊領導，但應用程式團隊可能會在切換期間參與驗證遷移計劃和測試。客戶通常會將雲端遷移作為基礎設施專案來處理，而不是作為應用程式遷移。這可能會導致遷移期間發生問題。
我們建議您在選擇遷移策略時，考慮應用程式團隊所需的參與。例如，與變更更多應用程式環境的轉換或重構策略相比，重新託管策略需要的應用程式團隊參與較少。如果應用程式擁有者可用性有限，請考慮使用 Rehost 或 replatform，而不是重構、重新定位或重新購買策略。
### 驗證遷移工作負載時沒有授權問題
當您將企業現成產品遷移至雲端時，授權可能會變更。您的授權合約可能著重於您的現場部署資產。例如，授權可能是由 CPU 或連結至特定 MAC 地址。或者，授權合約可能不包括在公有雲端環境中託管的權利。不過，與廠商重新交涉授權可以包含較長的前置時間，並為遷移提供硬性封鎖程式。
我們建議您在定義遷移範圍後，立即與您的來源或廠商管理團隊合作。授權也可能影響您的目標架構和遷移模式。
## 培訓
**Contents**
+ [為團隊提供新工具和程序的訓練](#tools-training)
### 為團隊提供新工具和程序的訓練
定義遷移策略之後，請花時間了解遷移和目標操作模型可能需要哪些訓練。在遷移期間，您可能會使用您組織的新工具 AWS Database Migration Service，例如 。主動訓練團隊可減少遷移階段期間遇到的延遲。
我們建議尋求主動知識轉移方法，提供以實際操作方式實驗工具的機會。例如， AWS Professional Services 為三個系統整合商 (SI) AWS 合作夥伴提供數個 Cloud Migration Factory 培訓課程，負責大型遷移。這可確保團隊在進入遷移階段時具有基本熟悉度。它還有助於識別主題專家 (SMEs)，他們可以在每個 SI AWS 合作夥伴團隊中作為一線呈報。
# 技術觀點
技術為加速大型遷移提供了良好的基礎。例如，Cloud Migration Factory 解決方案著重於如何為遷移提供end-to-end自動化。本節探討使用 技術實現所需規模和速度的一些最佳實務，並與範圍、策略和時間表保持一致。
總體原則是盡可能查看自動化領域。如果您的範圍內有數千部伺服器，手動執行任務可能是一項昂貴且耗時的工作。
若要執行遷移，通常會使用數種工具，如下所示：
+ 探索
+ 遷移實作
+ 組態管理資料庫 (CMDB)
+ 庫存試算表
+ 專案管理
這些工具用於不同的遷移階段，從評估到調動到實作。這些工具的選擇取決於業務目標和時間表。
規劃遷移階段之後，下一步是確保遷移團隊具備使用所需工具的技能。如果團隊缺乏技能或經驗，請規劃目標式訓練來提升技能集。如果可能，請建立事件，讓團隊可以在安全的環境中獲得遷移工具的經驗。例如，團隊是否可以遷移沙坑或實驗室伺服器來體驗工具？ 或者，初始開發工作負載是否可以用於學習目的？
## 自動化、追蹤和工具整合
**Contents**
+ [自動化遷移探索，以減少所需的時間](#discovery)
+ [自動化重複性任務](#repeating)
+ [自動化追蹤和報告以加速決策](#decision)
+ [探索可促進遷移的工具](#tooling)
### 自動化遷移探索，以減少所需的時間
大多數大型遷移計劃從了解遷移的範圍 （必須遷移的內容） 和制定策略 （遷移的方式） 開始。探索是其中的重要層面。擷取必要的中繼資料點，以形成遷移策略決策樹。若要逐步遷移工作負載，您必須識別所需的遷移中繼資料並將其匯入實作程序，例如遷移工廠。一種完全自動化的機制，可擷取、轉換、載入 (ETL) 遷移中繼資料可大幅減少探索程序所涉及的時間和工作量。
一位客戶為其遷移工廠開發了全自動化的資料輸入程序。具有所有遷移中繼資料的遷移波動計畫託管和維護在 Microsoft SharePoint 上的試算表中。對來源進行變更時，會啟動 AWS Lambda 函數，以在無需手動介入的情況下將資料載入遷移工廠。這種自動化的資料輸入程序有助於客戶減少手動工作、盡量減少人為錯誤，並加快速度。他們能夠將超過 1，000 個伺服器遷移至 AWS。
### 自動化重複性任務
在遷移實作階段，許多小型程序必須經常重複。例如，使用 AWS Application Migration Service (MGN) 時，您必須在遷移範圍內的每個伺服器上安裝 代理程式。
建置符合您特定業務和技術需求的遷移工廠，是實現成功進行大型遷移所需的效率和速度最有效的方式。遷移工廠提供整合和協同運作架構，使用標準化資料集來加速遷移。識別所有任務後，請花時間自動化所有可自動化的手動任務，以及規範性的 Runbook。
[Cloud Migration Factory](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/welcome.html) 解決方案是其中的範例。Cloud Migration Factory 旨在提供遷移自動化基礎，您可以在其上自動化組織特有的層面。例如，您可能想要更新 CMDB 中的旗標，以強調現場部署伺服器現在可以停用。在此案例中，您可以建立在遷移波結束時執行此任務的自動化。Cloud Migration Factory 有一個集中式中繼資料存放區，其中包含所有波動、應用程式和伺服器中繼資料。自動化指令碼可以連線至 Cloud Migration Factory，以取得該波中的伺服器清單，並相應地執行任何動作。Cloud Migration Factory 支援 [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)。
### 自動化追蹤和報告以加速決策
我們建議您建置自動化遷移報告儀表板來追蹤和報告即時資料，包括程式的關鍵效能指標 (KPIs)。遷移專案涉及整個組織的利益相關者，包括下列項目：
+ 應用程式團隊
+ 測試人員
+ 解除委任團隊
+ 架構師
+ 基礎設施團隊
+ 領導
若要執行其角色，這些利益相關者需要即時資料。例如，網路團隊必須知道即將發生的遷移波紋，以了解對內部部署資源與 之間共用連線的影響 AWS。領導團隊想要了解遷移完成的程度。擁有可靠、自動化的資料即時饋送可防止通訊錯誤，並提供做出決策的基礎。
一位大型醫療保健客戶正在努力結束資料中心，且截止日期即將到來。考慮到規模和複雜性，最初花費大量時間在追蹤和溝通利益相關者之間的遷移狀態。遷移團隊稍後使用 [Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/quick-bi.html) 建置自動化儀表板來視覺化資料，大幅簡化追蹤和通訊，同時提高遷移速度。
### 探索可促進遷移的工具
為您的遷移選擇正確的工具並不容易，特別是如果您組織中沒有人之前管理過大型遷移。
建議您花時間選擇合適的工具以支援遷移。此探勘可能涉及授權成本，但當您考慮更廣泛的計畫時，它可以提供成本效益。或者，您可能會發現內嵌在組織中的工具可提供類似的結果。例如，您可能已在資產中部署應用程式效能監控工具，以提供豐富的探索資訊。
由於缺乏熟悉度，技術客戶最初不願意在遷移期間執行自動探索工具。因此，SI AWS 合作夥伴必須為每個應用程式執行 5-10 小時的會議，以手動探索資產，包括伺服器名稱、作業系統版本和相依性。據估計，如果已使用探索工具，探索工作可能會減少超過 1，000 小時。
## 先決條件和遷移後驗證
**Contents**
+ [在遷移前階段建置登陸區域](#landing-zone)
+ [概述先決條件活動](#outline)
+ [實作遷移後檢查以持續改進](#post-checks)
### 在遷移前階段建置登陸區域
我們建議您事先建置 AWS 目標環境或登陸區域，而不是在遷移波動期間建置目標虛擬私有雲端 (VPCs) 和子網路。建置架構良好的登陸區域是遷移的先決條件。登陸區域應包含監控、控管、操作和安全控制。
在遷移之前建置和驗證登陸區域，可最大限度地減少在新環境中執行工作負載所帶來的不確定性。建立登陸區域後，利益相關者可以專注於遷移工作負載，而無需擔心帳戶或 VPC 層級管理的層面。
### 概述先決條件活動
除了登陸區域之外，請務必在遷移之前調整其他技術先決條件，尤其是前置時間較長的程序。例如，進行必要的防火牆變更，以允許資料從內部部署複寫到 AWS。及早溝通技術先決條件有助於準備和配置所需的資源。因為尚未符合先決條件，所以遷移至停滯的情況很常見。這不僅會影響進行中的遷移波動，還可能會在問題正在修復時推回所有未來遷移的日期。
一家金融服務公司，旨在執行大規模遷移至 AWS，目標是清空數個資料中心。不過，其頻寬在內部部署和 之間可用 AWS ，不足以達到預期的速度。不幸的是，增加頻寬需要新的連線，而且前置時間為三個月。這表示遷移速度在前三個月受到限制。
### 實作遷移後檢查以持續改進
最後，請記得實作遷移後驗證，例如操作整合、成本最佳化，以及控管和合規檢查。遷移後驗證包括評估先前遷移的工作負載，以找出學到應套用至未來波紋的技術經驗。
此外，這是實作成本控制操作的絕佳機會。例如，在遷移期間，您可能會決定將 AWS 執行個體的大小與現場部署資產相符，以減少效能測試的需求。現在，測試不再位於資料中心關閉關鍵路徑上，您可以使用 Amazon CloudWatch 來評估執行個體使用率，並判斷較小大小的執行個體是否合適。
為了說明此階段的重要性，大型技術客戶正在執行大型遷移，但最初不包含遷移後驗證。遷移超過 100 個伺服器之後，他們發現 AWS Systems Manager 代理程式 (SSM 代理程式） 未正確設定。所有先前遷移的伺服器都必須修復，且遷移會停止。客戶也發現執行個體的大小是初始預估的五倍，因此他們在每個遷移波結束時實作了成本檢查點。
# 程序觀點
程序帶來一致性，但也會演進，而且由於每個專案都是獨一無二的，因此容易變更。當您重複執行程序時，您將識別差距和改進空間，以便在失敗、學習、採用和反覆運算時增加巨大的優勢。這些變更可能會導致專案和企業在未來可以利用的新想法或創新，這為成長提供了促進品質和團隊信心的促進因素。
遷移中的程序可能很複雜，因為它們跨越了先前可能尚未連結的技術和界限。此觀點提供大型遷移特定需求的程序和指導。
## 為您的大型遷移做好準備
下列各節概述必要的核心原則，以確保您以明確的方向開始遷移之旅，並取得利益相關者對其成功至關重要的認可。
**Contents**
+ [定義業務驅動因素並溝通時間表、範圍和策略](#bus-drivers)
+ [定義明確的呈報路徑，以協助移除封鎖程式](#escalation)
+ [將不必要的變更降至最低](#change)
+ [提早記錄end-to-end程序](#end-to-end)
+ [記錄標準遷移模式和成品](#artifacts)
+ [為遷移中繼資料和狀態建立單一事實來源](#metadata)
### 定義業務驅動因素並溝通時間表、範圍和策略
接近大型遷移到 時 AWS，您會快速發現遷移伺服器的方法有很多種。例如，您可以執行下列操作：
+ 使用 重新託管工作負載[AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)。
+ 容器化您的應用程式，並將其託管在 [Amazon Elastic Container Service](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) (Amazon ECS) 或 [Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) (Amazon EKS) 受管容器平台上。
+ 將工作負載重新設計為完全無伺服器的應用程式。
若要判斷正確的遷移路徑，請務必從業務驅動因素向後工作。如果您的最終目標是提高業務敏捷性，您可能會偏好第二個模式，這涉及更多層級的轉型。如果您的目標是在年底之前清空資料中心，則由於重新託管提供的速度，您可以選擇重新託管工作負載。
大型遷移通常涉及廣泛的利益相關者，包括下列項目：
+ 應用程式擁有者
+ 網路團隊
+ 資料庫管理員
+ 執行發起人
識別遷移的業務驅動因素至關重要，並在文件中包含該清單，例如遷移計畫成員可存取的專案章程。此外，建立符合您目標業務成果的關鍵績效指標 (KPIs)。
例如，一位客戶想要在 12 個月內遷移 2，000 部伺服器，以實現他們清空資料中心的目標業務成果。不過，他們的安全團隊未符合此目標。結果導致數月的技術爭論是否錯過資料中心關閉日期，但進一步現代化應用程式，或最初重新託管以啟用及時的資料中心關閉，然後現代化應用程式 AWS。
### 定義明確的呈報路徑，以協助移除封鎖程式
大型雲端遷移計劃通常涉及廣泛的利益相關者。畢竟，您可能正在變更已經在內部部署託管幾十年的應用程式。每個利益相關者都有衝突的優先順序是很常見的。
雖然所有優先順序都可能驅動價值，但計劃可能會有有限的預算量和定義的目標結果。管理各種利益相關者並專注於目標業務成果可能具有挑戰性。當您將挑戰乘以遷移範圍內的數百或數千個應用程式時，此挑戰會更為複雜。此外，利益相關者可能會向具有其他優先事項的不同領導團隊報告。考慮到這一點，除了明確記錄目標業務成果之外，請務必定義明確的呈報矩陣，以協助移除封鎖程式。這可以節省大量時間，並協助讓各個團隊符合共同目標。
其中一個範例示範這是一家金融服務公司，其目標是在 12 個月內清空其主要資料中心。沒有明確的命令或呈報路徑，這會導致利益相關者制定他們所需的遷移路徑，無論時間和預算限制為何。在向 CIO 呈報之後，已設定明確的命令，並提供機制來請求必要的決策。
### 將不必要的變更降至最低
變更很好，但變更越多表示風險越大。當大型遷移的業務案例獲得核准時，最有可能是推動此計畫的目標業務成果，例如在特定日期之前離開資料中心。雖然技術人員通常想要重寫所有內容以充分利用 AWS 服務，但這可能不是您的業務目標。
一位客戶專注於公司整個 Web 規模基礎設施的兩年遷移 AWS。他們建立了兩週的規則作為一種機制，以防止應用程式團隊花費數月的時間重寫其應用程式。透過使用兩週規則，客戶能夠以一致的節奏維持長期遷移，此時必須移動數百個應用程式多年。如需詳細資訊，請參閱部落格文章[：兩週規則：在 10 天內重構雲端的應用程式](https://aws.amazon.com/blogs/enterprise-strategy/the-two-week-rule-refactor-your-applications-for-the-cloud-in-10-days/)。
我們建議將不符合業務成果的任何變更降至最低。相反地，請建置機制來管理未來專案中的這些額外變更。
### 提早記錄end-to-end程序
在大型遷移計劃的早期階段記錄完整的遷移程序和所有權指派。本文件對於教育所有利益相關者如何執行遷移及其角色和責任非常重要。文件也會協助您了解可能發生的問題，並在進行遷移時提供程序的更新和反覆運算。
在開發遷移專案期間，請確保了解任何現有的程序，並清楚記錄整合點和相依性。包括需要與外部程序擁有者互動的地方，包括變更請求、服務請求、廠商支援，以及網路和防火牆支援。了解程序之後，建議您在負責、負責、諮詢、告知 (RACI) 矩陣中記錄所有權，以追蹤不同的活動。若要完成程序，請識別遷移每個步驟中涉及的時間表，以建立倒數計時計劃。倒數計時計劃通常從工作負載遷移切換日期和時間向後運作。
此文件方法適用於在不到一年內 AWS 成功遷移至 並退出四個資料中心的多國家電公司。他們有六個不同的組織團隊和多個涉及的第三方，這引入了管理開銷，導致back-and-forth決策和實作延遲。Professional AWS Services 團隊與客戶及其第三方一起識別遷移活動的關鍵程序，並與各自的擁有者一起記錄。產生的 RACI 矩陣由所有參與的團隊共用和同意。客戶使用 RACI 矩陣和呈報矩陣，減輕了造成延遲的封鎖程式和問題。然後，他們可以提前結束資料中心。
在另一個使用 RACI 和呈報矩陣的範例中，保險公司能夠在不到 4 個月內離開資料中心。客戶了解並實作共同的責任模型，並遵循詳細的 RACI 矩陣，以在整個遷移過程中追蹤每個程序和活動的進度。因此，客戶在實作的前 12 週能夠遷移超過 350 個伺服器。
### 記錄標準遷移模式和成品
將此視為建立實作的 Cookie 切入器。可重複使用的參考、文件、執行手冊和模式是擴展的關鍵。這些日誌記錄未來遷移專案可以重複使用和避免的體驗、學習、陷阱、問題和解決方案，大幅加速遷移。模式和成品也是有助於改善流程並引導未來專案的一項投資。
例如，一位客戶正在執行為期一年的遷移，其中應用程式正由三個不同的 SI AWS 合作夥伴遷移。在早期階段，每個 AWS 合作夥伴都使用自己的標準、執行手冊和成品。這會對客戶團隊造成許多壓力，因為相同的資訊可能會以不同的方式呈現給他們。在這些早期的痛苦之後，客戶建立了要在遷移中使用的所有文件和成品的集中擁有權，其中包含提交建議變更的程序。這些資產包括下列項目：
+ 標準遷移程序和檢查清單
+ 網路圖表樣式和格式標準
+ 基於業務重要性的應用程式架構和安全標準
此外，這些文件和標準的任何變更都會每週傳送給所有團隊，而且每個合作夥伴都必須確認收到並遵守任何變更。這大幅改善了遷移專案的通訊和一致性，而且當另一個業務單位的個別大型遷移工作開始時，該團隊能夠採用現有的程序和文件，大幅加速成功。
### 為遷移中繼資料和狀態建立單一事實來源
在規劃大型遷移時，建立事實來源對於讓各種團隊保持一致並啟用資料驅動型決策至關重要。當您開始此旅程時，您可能會找到許多可使用的資料來源，例如組態管理資料庫 (CMDB)、應用程式效能監控工具、庫存清單等。
或者，您可能會發現只有幾個資料來源，而且您必須建立機制來擷取所需的資料。例如，您可能需要使用探索工具來探索技術資訊，以及調查 IT 領導者以取得商業資訊。
請務必將各種資料來源彙整為單一資料集，以供您用於遷移。然後，您可以使用單一事實來源，在實作期間追蹤遷移。例如，您可以追蹤哪些伺服器已遷移。
金融服務客戶想要遷移所有工作負載， AWS 以專注於使用已提供的資料集規劃遷移。此資料集有關鍵差距，例如業務關鍵性和相依性資訊，因此計畫開始了探索練習。
在另一個範例中，同一產業的公司根據對其伺服器基礎設施庫存的out-of-date了解而進入遷移波動實作。他們很快開始看到遷移數量減少，因為資料不正確。在這種情況下，應用程式擁有者不了解，這表示他們無法及時找到測試人員。此外，資料不符合其應用程式團隊已完成的解除委任，因此伺服器在執行時並未用於商業用途。
## 執行大型遷移
在您建立業務成果並將策略傳達給利益相關者後，您可以繼續規劃如何將大型遷移的範圍切入永續遷移事件或波浪。下列範例提供制定波動計畫的關鍵指引。
**Contents**
+ [事先規劃遷移波紋，以確保穩定的流程](#plan-waves)
+ [將波動實作和波動規劃保留為個別的程序和團隊](#separate)
+ [從小開始，以獲得絕佳的成果](#start-small)
+ [將切換時段數量降至最低](#cutover-numbers)
+ [快速失敗、套用體驗和反覆運算](#iterate)
+ [別忘了追溯性](#retrospective)
### 事先規劃遷移波紋，以確保穩定的流程
規劃遷移是計畫最重要的階段之一。它會說明「如果您無法規劃，您計劃失敗」。事先規劃遷移波紋可讓專案在團隊更積極應對遷移情況時快速流動。它有助於更輕鬆地擴展專案，並隨著專案需求增加和變得複雜，改善決策和預測。事先規劃也會改善團隊適應變更的能力。
例如，大型金融服務客戶正在處理資料中心退出計畫。一開始，客戶以循序方式規劃遷移波，先完成一個波，再開始規劃下一個波。此方法可減少準備時間。當利益相關者收到他們的應用程式正在遷移到的通知時 AWS，他們在開始遷移之前仍然需要執行幾個步驟。這增加了對程式的重大延遲。在客戶實現這一點之後，他們實作了一個全面且以未來為重心的遷移規劃串流，其中遷移波紋是幾個月前規劃的。這為應用程式團隊提供了足夠的通知，以執行其遷移前活動，例如通知 AWS 合作夥伴、授權分析等。然後，他們可以從程式的關鍵路徑中移除這些任務。
### 將波動實作和波動規劃保留為個別的程序和團隊
當波動規劃和波動實作團隊是分開的，這兩個程序可以平行運作。透過通訊和協調，這可避免降低遷移速度，因為沒有足夠的伺服器或應用程式已準備好達到預期的速度。例如，遷移團隊可能需要每週遷移 30 個 伺服器，但目前波動時只有 10 個 伺服器準備就緒。此挑戰通常由下列原因造成：
+ 遷移實作團隊未參與波動規劃，且在波動規劃階段收集的資料尚未完成。遷移實作團隊必須在開始波動之前收集更多伺服器資料。
+ 遷移實作排定在波動規劃後立即開始，沒有緩衝。
請務必事先規劃波浪，並在準備和開始波浪實作之間建立緩衝區。確保波動規劃團隊和遷移團隊一起合作收集正確的資料並避免重做也很重要。
### 從小開始，以獲得絕佳的成果
計劃啟動小型 ，並在每次後續波動時增加遷移速度。初始波動應該是單一的小型應用程式，少於 10 個 伺服器。在後續波紋中新增其他應用程式和伺服器，以建立完整的遷移速度。優先考慮較不複雜或有風險的應用程式，並按排程提高速度，讓團隊有時間調整以一起工作並學習程序。此外，團隊可以識別並實作每個波次的程序改善，大幅改善後續波次的速度。
一位客戶一年遷移超過 1，300 個 伺服器。從試行遷移和幾個較小的波浪開始，遷移團隊能夠識別多種方法來改善稍後的遷移。例如，他們先前已識別新的資料中心網路區段。他們在程序初期與其防火牆團隊合作，制定防火牆規則，以允許與遷移工具進行通訊。這有助於防止未來波紋出現不必要的延遲。此外，團隊也能夠開發指令碼，以協助在每次波動時自動化更多探索和切換程序。從小開始，有助於團隊專注於早期程序改進，並大幅提高他們的信心。
### 將切換時段數量降至最低
大量遷移需要有紀律的方法來推動擴展。在某些區域過於靈活是大型遷移的反模式。透過限制每週切換時段的數量，花在切換活動上的時間具有較高的值。
例如，如果切換時段太彈性，您最後可能會有 20 個切換，每個 切換有 5 個伺服器。反之，您可以有兩個切換，每個切換有 50 個 伺服器。由於每個切換的時間和精力都很類似，因此切換越少，越大可減輕排程的操作負擔，並限制不必要的延遲。
一家大型技術公司在合約到期前嘗試從幾個租賃的資料中心遷移。缺少過期時間會導致昂貴的短期續約期限。在遷移之前，允許應用程式團隊指定遷移排程直到最後一分鐘，包括在切換前幾天因任何原因選擇退出遷移。這導致專案的早期階段發生許多延遲。通常，客戶必須在最後一分鐘與其他應用程式團隊進行協商以填寫。客戶最終提高了他們的規劃紀律，但此早期錯誤對遷移團隊造成持續壓力。整體排程的延遲會導致某些應用程式無法及時離開資料中心。
### 快速失敗、套用體驗和反覆運算
每個遷移一開始都有陷阱。提早失敗有助於團隊學習、了解瓶頸，並將學到的經驗應用到更大的波浪。預期遷移中的前兩個波會緩慢，原因如下：
+ 團隊成員正在調整彼此和程序。
+ 大型遷移通常涉及許多不同的工具和人員。
+ 整合、測試、失敗、學習和持續改善end-to-end程序需要一些時間。
問題在前幾波期間很常見且預期會發生。請務必了解並與整個組織溝通，因為有些團隊可能不喜歡嘗試新事物並失敗。失敗可能會阻止團隊，並成為未來遷移的封鎖程式。確保每個人都了解初始問題是任務的一部分，鼓勵每個人都嘗試失敗是成功遷移的關鍵。
一家公司計劃在 24-36 個月內遷移超過 10，000 個 伺服器。為了實現該目標，他們需要每月遷移近 300 個 伺服器。不過，這並不表示他們從第一天遷移了 300 個 伺服器。第一波波是學習波，以便團隊可以了解事物的運作方式，以及誰有權執行動作。他們也識別出可改善程序的整合，例如與 CMDB 和 CyberArk 整合。他們使用學習波紋來失敗、改善和再次失敗，改善程序和自動化。6 個月後，他們可以每週遷移超過 120 個 伺服器。
### 別忘了追溯性
這是敏捷程序的重要部分。這是團隊進行溝通、調整、學習、同意和向前邁進的地方。最基本層級的回顧是回顧、討論發生的情況、判斷哪些情況順利，以及哪些需要改進。然後，可以根據這些討論來建立改進。回顧性圍繞經驗教訓的概念來包裝一些形式或程序。回溯性很重要，因為為了實現大規模遷移取得成功的規模和速度，流程、工具和團隊必須不斷發展和改進。追溯性可以在其中發揮重要作用。
在程式結束之前，不會進行傳統課程學習的工作階段，因此這些課程通常不會在下一次遷移波動開始時進行檢閱。大型遷移時，學到的經驗應套用至下一波波，並且應該是波規劃程序的關鍵部分。
對於一個客戶，每週回顧會保留，以討論並記錄從切換中學到的經驗教訓。在這些工作階段中，他們發現了範圍從程序角度或自動化進行簡化的區域。這導致實作具有特定活動、擁有者和自動化指令碼的倒數時間排程，以在切換期間將手動任務降至最低，包括驗證第三方工具和 Amazon CloudWatch 代理程式安裝。
在另一家大型技術公司中，團隊持有定期回顧，以識別先前遷移波紋的問題。這使得程序、指令碼和自動化改善，在計畫過程中平均遷移時間減少了 40%。
## 其他考量
許多區域必須納入大型遷移計畫。下列各節提供必須考量的其他項目想法。
**Contents**
+ [隨需清理](#clean-up)
+ [針對任何其他轉換實作多個階段](#phases)
### 隨需清理
如果遷移的成本是預期成本的 10 倍，而且在用於遷移的資源關閉和清除之前，專案不會完成，則不會將其視為成功。此清除應該是遷移後活動的一部分。它可確保您不會將未使用的資源和服務留在環境中，而這些資源和服務會新增到成本中。遷移後清理也是防止暴露您環境的威脅和漏洞的良好安全實務。
移至 的兩個關鍵結果 AWS 雲端 是節省成本和安全性。保留未使用的資源可能會破壞轉移到雲端的業務目的。最常見的未清除資源包括下列項目：
+ 測試資料
+ 測試資料庫
+ 測試帳戶，包括防火牆規則、安全群組和網路存取控制清單 （網路 ACL) IP 地址
+ 佈建用於測試的連接埠
+ Amazon Elastic Block Store (Amazon EBS) 磁碟區
+ 快照
+ 複寫 （例如停止從內部部署到 的資料複寫 AWS)
+ 耗用空間的檔案 （例如用於遷移的臨時資料庫備份）
+ 託管遷移工具的執行個體
在錯誤清除實務的一個範例中，SI AWS 合作夥伴未在成功遷移後移除複寫代理程式。稽核 AWS 發現已遷移的複寫伺服器和 EBS 磁碟區每月成本為 20，000 美元 (USD)。為了緩解此問題， AWS Professional Services 建立了自動化稽核程序，在仍複寫過時通知 SI AWS 合作夥伴。然後，SI AWS 合作夥伴可以對未使用和過時的執行個體採取動作。
對於未來的遷移，採用程序來定義遷移後 Hypercare 期間為 48 小時，以確保平台順利採用。然後，客戶的基礎設施團隊提交現場部署伺服器的除役請求。建議在核准解除委任請求時，會從應用程式遷移服務主控台移除個別波動的伺服器。
### 針對任何其他轉換實作多個階段
執行大型遷移時，請務必專注於您的核心目標，例如資料中心關閉或基礎設施轉型。在較小的遷移中，範圍凹陷可能會產生最小的影響。不過，幾天的額外工作量乘以可能的數千部伺服器，可能會為程式增加大量時間。此外，其他變更也可能需要更新支援團隊的文件、程序和訓練。
若要克服潛在的範圍模糊，您可以實作多階段遷移方法。例如，如果您的目標是清空資料中心，第 1 階段可能只包含盡可能 AWS 快速地將工作負載重新託管到 。工作負載重新託管後，第 2 階段可以實作轉型活動，而不會危及目標業務成果。
例如，一位客戶計劃在 12 個月內結束資料中心。不過，其遷移涵蓋了其他轉換活動，例如推出新的應用程式效能監控工具和升級作業系統。超過 1，000 部 伺服器在遷移範圍內，因此這些活動會對遷移造成重大延遲。此外，此方法需要使用新工具進行訓練。客戶稍後決定實作多階段方法，並初步專注於重新託管。這會增加其遷移速度，並降低不符合資料中心關閉日期的風險。