

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

# 調動階段
<a name="mobilize-phase"></a>

準備人力資源和資源以大規模遷移企業的下一個步驟是將調動活動分解為不同的工作流。雖然調動階段的目標是商業應用程式的遷移，但此階段也提供機會為工具、程序和文化奠定基礎，以大規模加速遷移。這些工作流大部分可在評估階段完成後平行執行。在此階段期間，應執行下列工作流：
+ [詳細的商業案例](detailed-business-case.md)
+ [詳細的產品組合探索](detailed-portfolio-discovery.md)
+ [應用程式遷移](application-migration.md)
+ [遷移控管](migration-governance.md)
+ [登陸區域](aws-landing-zone.md)
+ [安全性、風險和合規性](security-risk-compliance.md)
+ [操作](operations.md)
+ [人員：技能、文化、變革和領導力](people.md)

以下章節會詳細說明這些內容。

# 詳細的商業案例
<a name="detailed-business-case"></a>

包含目前內部部署成本、新 AWS 成本和遷移成本的詳細多年商業遷移案例，有助於讓利益相關者和高階主管保持一致。

**目標**
+ 確定遷移成本。
+ 估算遷移到 可以節省多少成本 AWS。
+ 估算遷移的其他商業利益。
+ 決定目標遷移的長度。
+ 決定您要遷移的工作負載，以及在哪一年遷移。
+ 輸入每個工作負載的詳細庫存。

**結果**
+ 多年遷移商業案例
+ 遷移成本

**AWS 合作夥伴和工具**

AWS RISC Networks、Deloitte、Cloudamize、TSO Logic 和 Apptio 等合作夥伴在此領域擁有工具和經驗。

# 詳細的產品組合探索
<a name="detailed-portfolio-discovery"></a>

這是您開始將片段拉在一起並制定遷移策略的地方。在此階段，您想要考慮雲端旅程適合組織大型業務策略的位置，並尋找符合願景的機會。具有支援業務案例和徹底應用程式遷移計劃的協調一致遷移策略，為雲端採用的成功奠定了適當的基礎。

遷移策略的一個關鍵方面是收集應用程式產品組合資料，並根據[七個遷移 R](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html) 合理化這些資料：rehost、replatform、refactor/re-architect、repurase、relocate、retift 和 retain。您可以使用七個 R 來建立遷移波動計畫，以分類環境中的內容。接著，將這些類別與相互依存性、要遷移的技術複雜性，以及如何遷移每個應用程式或一組應用程式的相關資訊混合。根據七個 R 分析應用程式後，您可以概述產品組合中每個應用程式的遷移計劃。這是一個迭代計劃，在您進行遷移、建立可信度、學習新功能，以及更了解現有的資產時，將會成熟。

**目標**
+ 針對所有範圍內的應用程式，開發遷移群組的優先順序清單，包括應用程式和相關聯的基礎設施。
+ 定義必要的業務和基礎設施資料元素，並建議資料收集工具。
+ 與業務和 IT 領導團隊合作，定義遷移驅動因素，最終定義產品組合計劃。
+ 為應用程式產品組合建立高保真遷移計畫，其中包含下列活動：
  + 探索目前狀態環境，包括所有應用程式和支援基礎設施。
  + 判斷應用程式和基礎設施相依性。
  + 記錄應用程式重要性、生命週期和商業週期。
  + 將應用程式和基礎設施分組為遷移群組和模式。
  + 確定遷移準備度和適用性、目標狀態設計和遷移模式。
  + 制定優先遷移排程。

**結果**
+ 最初四個遷移衝刺的高逼真度優先遷移排程
+ 應用程式和基礎設施資料足以分組和排程整個應用程式產品組合

**AWS 合作夥伴和工具**

如果您需要協助了解 IT 產品組合，您可以與 RISC Networks、Cloudamize 和 Deloitte 等 AWS 合作夥伴合作。

**操作指南**
+ [產品組合探索和分析](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-portfolio-discovery/)

# 應用程式遷移
<a name="application-migration"></a>

應用程式遷移工作流將來自其他工作流的輸出與生產應用程式的遷移整合到 AWS 雲端。此工作流會引導您的資源，並引導您完成應用程式遷移挑戰、最佳實務、敏捷架構、工具和程序，這些都可以成功套用至任何大規模遷移工作。

**目標**

將商業應用程式從內部部署遷移至 AWS 雲端：
+ 定義如何選取遷移的應用程式並排定其優先順序。
+ 了解將應用程式遷移到其中的經驗證最佳實務 AWS。
+ 透過測試應用程式，驗證您的 AWS 登陸區域、操作 Runbook 和安全程序手冊 AWS。
+ 透過實作體驗，培訓內部員工了解 AWS 服務 和 AWS Partner 工具。
+ 了解不同應用程式類型的業界認可遷移工具和技術。
+ 使用來自不同[遷移模式](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/)的現有 epics （後端日誌） 來入門。

**結果**
+ 透過應用程式部署和測試來驗證 AWS 登陸區域的不同元件
+ 透過在 中執行的應用程式上部署、監控和報告，驗證概述的操作模型 （操作工作流程的輸出） AWS 雲端
+ 了解可擴展的敏捷程序和遷移模式，以遷移不同的應用程式
+ 了解如何設計目標架構，以及如何使用資料遷移、伺服器遷移和廠商工具進行自動遷移
+ 訓練資源 AWS 服務，並提供實作遷移體驗
+ 透過即時稽核在 上執行的應用程式，驗證您的安全程序手冊 AWS
+ 遷移交付程序的學習、實作和驗證，包括資源數量、速度 （遷移速度）、品質保證、發行管理，以及與受管服務供應商 (MSPs整合

**AWS 合作夥伴和工具**

當您在遷移一些應用程式和組織支援的計劃方面有一些基礎經驗時，是時候加速遷移並實現擴展了。遷移交付合作夥伴，例如 2nd Watch 和 Accenture，可以在遷移的每個階段提供協助。遷移 Marketplace 合作夥伴，例如 RiverMeadow Software 和 Attunity，也可以提供協助，而且您可以使用工具和服務，例如 [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/)和 [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/)。如需所有 AWS 遷移合作夥伴和解決方案的完整清單，請參閱[AWS 遷移和現代化能力合作夥伴](https://aws.amazon.com/migration/partner-solutions/)網站。

# 遷移控管
<a name="migration-governance"></a>

遷移控管工作流程包括管理遷移範圍、排程、資源計劃、問題和風險，以及與所有利益相關者的通訊。多個應用程式會在多個串流中遷移，影響多個團隊，因此早期專注於規劃有助於組織專案。遷移計畫會考慮關鍵因素，例如工作負載遷移的順序、需要資源的時間，以及如何追蹤遷移進度。我們建議敏捷交付方法、專案控制最佳實務、健全的商業溝通計畫，以及明確定義的交付方法。

**目標**

管理範圍、排程、資源計畫、問題和風險、協調，以及與所有利益相關者的溝通：
+ 設定由此階段中定義之工作流程內部資源組成的 scrum 團隊。
+ 識別要從內部部署遷移到的 10 到 30 個應用程式 AWS。
+ 檢閱您目前的狀態專案管理方法和功能。
+ 定義將在專案期間使用的專案管理敏捷方法和工具。
+ 識別每個工作流的高階團隊。
+ 定義專案章程、報告和呈報程序。
+ 促進整個專案中群組的協調和活動。

**結果**
+ 為準備和規劃階段的所有工作流程設定具有 epics 的敏捷程式。
+ 提供探索、轉換和部署複雜工作負載元件集的考量和遷移實作計畫。

**AWS 合作夥伴和工具**

AWS 遷移能力合作夥伴可以透過以專業服務的形式提供人員、工具和教育，協助您完成遷移的每個階段，加速結果。這些合作夥伴是[受管服務供應商 (MSPs)](https://aws.amazon.com/partners/msp/)，或與經過稽核的 MSP AWS有關係，協助客戶持續支援 AWS 工作負載。若要進一步了解，請參閱 AWS[遷移和現代化能力合作夥伴](https://aws.amazon.com/migration/partner-solutions/)。

**操作指南**
+ [設定敏捷程式以加速雲端遷移](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-program-implementation/)

# 登陸區域
<a name="aws-landing-zone"></a>

登陸區域是基礎 AWS 環境的協同運作架構。它提供一個基準，以開始使用多帳戶架構、身分和存取管理、管控、資料安全、網路設計和記錄。

AWS 有兩種建立登陸區域的選項：使用 的服務型登陸區域，[AWS Control Tower](https://aws.amazon.com/controltower/)以及您建置的自訂登陸區域。每個選項都需要不同層級 AWS 的知識。

AWS Control Tower 透過自動化登陸區域的設定來協助您節省時間，以便您可以執行安全且可擴展的工作負載。 AWS Control Tower 由 管理 AWS ，並使用最佳實務和指導方針來協助您建立基礎環境。 AWS Control Tower 使用整合的服務，例如 [AWS Service Catalog](https://aws.amazon.com/servicecatalog/)和 [AWS Organizations](https://aws.amazon.com/organizations/)，在您的登陸區域中佈建帳戶，並管理這些帳戶的存取。

**目標**

使用下列項目的初始組態建立登陸區域：
+ 帳戶結構
+ 網路結構
+ 預先定義的身分和帳單架構
+ 預先定義的使用者可選套件
+ 能夠自訂和設定

**結果**
+ 已定義且安全的登陸區域，已準備好進行遷移和進一步自訂

**操作指南**
+ [設定安全且可擴展的多帳戶 AWS 環境](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-aws-environment/welcome.html)

**相關資源**
+ [AWS Control Tower](https://aws.amazon.com/controltower/)
+ [AWS Service Catalog](https://aws.amazon.com/servicecatalog/)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [在您的登陸區域建構安全與控管 ](https://www.youtube.com/watch?v=zVJnenaD3U8)(AWS re：Invent 2019 簡報）

# 安全性、風險和合規性
<a name="security-risk-compliance"></a>

安全性、風險和合規工作流定義了結構化方法來協助您建立對 的信心 AWS。它還啟用了基礎安全、風險和合規功能，可以加速遷移專案的準備和規劃。交付方法是以 AWS CAF 安全觀點為基礎，為準備將業務工作負載遷移到其中的安全團隊提供更詳細的指導 AWS。此工作流利用虛擬資料中心的概念來處理最低基準安全性和合規控制。虛擬資料中心旨在使用一或多個雲端安全交付團隊，透過敏捷的開發程序建構。

**目標**

安全性觀點為下列項目提供建議的初始組態：
+ 身分和存取管理模型
+ 記錄和監控模型
+ 基礎設施安全性
+ 資料保護
+ 事件回應

**結果**

可參考的手冊，由相關程式碼範例支援，並涵蓋以下五個使用 的安全和稽核任務核心主題 AWS 服務：
+ 身分與存取管理
+ 偵測性控制
+ 基礎設施安全性
+ 資料保護
+ 事件回應

# 作業
<a name="operations"></a>

操作工作流的目標是檢閱您目前的操作模型，並開發操作整合方法，以在遷移至 時支援未來狀態的操作模型 AWS。操作模型應涵蓋人員、程序和工具之間的關係，以支援實現組織目標。Workstream 擁有者會根據工具、程序和人員的最終狀態操作模型來識別和記錄高階差距。接著會建立藍圖優先順序以進行實作。此路線圖會受到其他遷移工作流的影響，並且會因為安全、人員、 AWS 登陸區域和其他專案工作流之間的許多相互依存性而影響其他遷移工作流。

**目標**

建立營運建構的藍圖以擴展 AWS：
+ 識別所需的 IT 服務管理 (ITSM) 狀態和支援模型。
+ 在內部部署和雲端中檢閱目前的操作實務 （工具、人員、程序）。
+ 識別擴展操作的潛在漏洞。
+ 檢閱業務持續性規劃 (BCP)，並建立計畫以解決對營運的任何潛在影響。
+ 識別執行遷移將如何影響正常操作。
+ 識別將與雲端環境互動的營運支援組織和 AWS 合作夥伴。

**結果**
+ 改善營運狀態，以及增強型服務層級協議 (SLAs) 和營運層級協議 (OLAs)
+ 操作孤島的 Runbook 和設計指南，例如備份、監控和部署
+ 上的操作手冊 AWS
+ 業務持續性規劃/災難復原 (BCP/DR) 手冊
+  AWS 記錄和定義的 ITSM

**AWS 合作夥伴和工具**

隨著應用程式遷移和舊系統淘汰，您的操作模型會變成一組永久的人員、程序和技術，不斷向現代操作模型迭代。AppDynamics、New Relic 和 Dynatrace 等 AWS 合作夥伴可協助您在將更多操作移至雲端時，繼續迭代您的操作模型。

**操作指南**
+ [中的現代化操作 AWS 雲端](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-operations-integration/)

# 人員：技能、文化、變革和領導力
<a name="people"></a>

此工作流對於建立遷移準備和大規模執行遷移至關重要。雲端遷移的影響將影響整個組織，並顯著影響組織文化。此外，您的組織文化將影響您的雲端之旅。這些文化影響、組織的變革接受度、先前的變革成功和失敗、組織溝通模式、組織結構，以及現有的員工訓練和啟用策略，都是建置成功遷移方法的重要元素。若要為企業遷移做好準備，您必須擁有大量關鍵的生產 AWS 經驗和已建立的操作程序。您還必須擁有一個 Cloud Center of Excellence (CCoE)，專用於調動適當的資源，並領導組織解決在大規模遷移工作過程中面臨的許多組織和業務轉型挑戰。

**目標**
+ 設計負責調動關鍵雲端資源的團隊。
+ 透過為未來的營運狀態設計團隊，定義組織如何建置和實作其雲端策略。
+ 建立具有單一執行緒擁有權的專用團隊，以及強大、可見、參與的主管贊助。
+ 設定在整個遷移過程中要管理的功能區域。
+ 開始建立雲端控管模型、一組標準、最佳實務，以及指導方針或原則。
+ 使用 [AWS Change Acceleration 6-Point架構和 Organizational Change Management Toolkit](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-ocm/)，提供完整的啟用工具套件，以支援您的雲端採用專案。

**結果**
+ 變更管理風險文件
+ 識別高階變更影響 （依角色和主要程序）
+ 主要利益相關者的映射
+ 通訊傳訊策略和平台
+ 初始通訊計劃和簡訊矩陣
+ 變更管理工作計畫 （初始）
+ 組織加速章程
+ 人員採用/加速團隊結構 （已記錄和加入）
+ 組織加速目標的定義
+ 未來狀態人員配置模型 （目標組織結構）
+ 變更風險計分卡 （風險管理）
+ 領導力一致性文件
+ 利益相關者報告節奏 （利益相關者評估）
+ 變更區域影響分析、利益相關者型評估，以及變更影響調查結果和緩解建議
+ 組織整備度評估報告
+ 變更策略
+ 通訊策略
+ 參與策略
+ 訓練策略
+ 風險緩解策略
+ 變更加速贊助藍圖

**操作指南**
+ [透過文化、變革和領導力加速雲端採用](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-ocm/)