本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 遷移階段
<a name="migrate-phase"></a>

大規模遷移包含準備和規劃階段期間定義和測試的建置區塊、程序、工具、資源和方法。使用先前階段中學到的最佳實務和經驗教訓後，您可以實作*遷移工廠*，這是透過自動化和敏捷交付擴展實作和操作的藍圖。

## 遷移工廠
<a name="migration-factory"></a>

在遷移專案的橫向擴展階段，您將有多個團隊同時運作。有些 會在重新託管和次要轉換模式中支援大量遷移。這些團隊稱為*遷移工廠*。您的遷移工廠將提高遷移計劃的速度，讓多個衝刺團隊並行工作。企業應用程式產品組合的 20-50% 由可由工廠方法最佳化的重複模式組成。這是敏捷的交付模式，請務必建立版本管理計劃。您的計劃應基於準備和規劃階段期間產生的目前工作負載和資訊。它應該持續針對未來的遷移波紋和未來的遷移團隊進行最佳化。我們建議您有支援每個團隊三個衝刺的應用程式待處理項目。如果您有影響排程的問題，這可讓您重新排定應用程式的優先順序。

更大且更複雜的應用程式通常會遵循重構/重新架構模式。它們通常由應用程式擁有者在規劃的發行週期中執行。工廠團隊是自給自足的，包含五到六個跨職能角色。其中包括營運、商業分析師和擁有者、遷移工程師、開發人員和 DevOps 專業人員。以下是特別專注於遷移工廠團隊的範例：
+ 託管遷移團隊會遷移不需要重大變更的大量、低複雜度應用程式。這些團隊會利用遷移自動化工具。此方法已整合至patch-and-release版本管理程序。
+ Replatform 遷移團隊設計並遷移需要變更平台或應用程式架構中可重複變更的應用程式。
+ 重構/重新架構遷移團隊 （多個） 設計和遷移具有許多相依性的複雜或核心業務應用程式。在大多數情況下，開發和技術營運團隊支援此業務能力。遷移會成為該團隊計劃內的發行週期或幾個發行週期。其中許多都可以在進行中，雲端商業辦公室 (CBO) 負責追蹤遷移完成的時間、風險和問題。此團隊擁有應用程式遷移程序。

要考慮的項目：
+ 執行產品組合分析以了解所有應用程式的常見模式，以協助為工廠團隊建立可重複的工作，以有效率地實作。
+ 使用 AWS Partner 協助解決資源限制，因為您的團隊支援一般業務活動。 AWS 和 AWS Partner 社群可以為資料庫、應用程式開發和遷移工具等特定主題提供專門的資源。

**操作指南**
+ [使用 Cloud Migration Factory 自動化大規模伺服器遷移](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/welcome.html)