產品組合分析和遷移規劃

為應用程式產品組合和相關聯的基礎設施建立基準 – 迭代從探索加速和初始規劃階段累積的產品組合層級資料，以縮小差距並產生整個應用程式產品組合的高階檢視。在此階段，精簡application-to-infrastructure映射、用量資料和應用程式中繼資料屬性至關重要。這些屬性包括擁有權、關鍵性和每個應用程式的主要函數。

取得和分析相依性資料 （通常是使用專門的探索工具） – 為了驗證應用程式並協助建立遷移波動計畫，高可信度的應用程式相依性資料是此階段的關鍵。相依性資料包括通訊資料，例如系統之間的通訊量和頻率，以及非技術相依性，例如操作考量。這些相依性決定哪些應用程式必須同時移動，以及哪些應用程式可以從不同的位置操作。

識別和驗證合規和法規要求 – 識別和驗證架構、規則、證據和文件要求。 

將假設轉換為事實 – 在先前階段中擔任了多少？ 在這個階段中，將假設數量減少到最低，這是關鍵。

建立遷移產品組合合理化模型的基準 – 從先前階段反覆運算模型 （例如，應用程式優先順序條件和 6 Rs 決策樹）。透過將模型套用至整個應用程式產品組合來驗證模型。

記錄可衡量的業務成果 – 為了使遷移波紋符合業務目標，請識別業務成果和每個遷移波紋的相關關鍵主要指標 (KPI)。

發展方向性商業案例 – 將基準取代為實際使用率和成本資料，並根據更新的波動計畫調整遷移成本。擴大涵蓋範圍，以納入每個預期業務成果的完整預期價值，例如降低成本、改善 IT 生產力、提高彈性和提高靈活性。

記錄和傳達關鍵日期 – 記錄和傳達令人信服的事件 （例如資料中心退出日期、合約和授權合約續約）、應用程式發行週期、要避免的遷移日期、技術重新整理週期和人員可用性。

分析波動規劃的成本和風險 – 可以支援或容忍多少平行變更？ 分析人員需求、風險識別和緩解、重要性和影響。

識別技能需求 – 支援雲端中不同工作負載類型的預測準備程度為何？ 遷移波動計畫是否與預計準備度一致？ 支援團隊是否可以滿足波動計畫要求？

文件內部程序 – 記錄影響雲端遷移的目前程序資訊，例如變更管理、服務管理、架構審查委員會、風險評估和核准工作流程。

建立遷移波動計畫 – 若要建立波動計畫，請結合此清單中先前討論的所有元素。將優先順序條件套用至產品組合，並分析相依性以建立應用程式的波紋。將平台和遷移整備納入遷移波動計畫。實作 AWS 基礎設施和服務需要多長時間？ 安全性和操作準備度需要什麼？ 波動持續時間有何影響？ 實作遷移工具需要多長時間？ 考量網路和系統用量，複寫資料需要多長時間？ 什麼是切換時段？ 復原需要多長時間？

更新工作流程 – 建立將產品組合和詳細應用程式評估資料饋送至遷移和登陸區域工作流程的程序。確保這些工作流清楚概述其資料需求。

高保真度應用程式和基礎設施庫存

每個應用程式的高階遷移策略

詳細的商業案例

高可信度遷移波動計畫

確保應用程式平均分佈在遷移波動計畫中。考慮關鍵性和複雜性，以避免可能會建立封鎖程式或延遲遷移的複雜性問題。

在前兩個波中優先考慮非關鍵、簡單的應用程式。

專注於結合優先順序、相依性和業務驅動因素，以反覆執行波動計畫。

建立波動計畫時，請考慮雲端基礎設施、安全性和營運準備程度 （包括技能）。

建構波動計畫，讓遷移波動的長度通常在 4-8 週之間概述應用程式旅程。每個波動應涵蓋下列項目：