探索加速和初始規劃

了解業務驅動因素

識別現有的資料來源

評估自動化探索工具的需求

建立應用程式優先順序和遷移策略選擇的基礎模型

產品組合的初步分析

識別初始遷移候選者

建立用於遷移的定向商業案例

初始計劃的概述。

確定利益相關者 – 誰會受到遷移的影響？ 誰是決策者？ 誰會從此遷移中受益？ 誰負責執行遷移？

識別業務驅動因素 – 由於遷移 （例如，業務轉型、成本降低、敏捷性） 而追求的業務成果和目標為何？ 此資訊將是遷移策略和優先順序的關鍵決定因素。

識別現有的資料來源 – 識別和記錄現有的資料來源，例如人員、工具、文件。為每個來源指派信任層級。例如，程式設計或自動化來源比機構知識或文件更受信任。隨著時間的推移，低信任的資料來源將被更高信任的資料來源取代。

建立應用程式和基礎設施的初始清查 – 識別應用程式名稱、主要函數、重要性、IT 環境、高階合規和法規要求，以及已知的相依性。哪些 IT 資產與應用程式相關聯？ 識別產品名稱和版本、歷史效能資料、已知問題和風險。

識別資料差距和探索需求 – 分析資料差距並評估採購自動化探索工具的需求。探索工具投資決策應該有提高資料整體可信度的必要，以便進行準確分析。為了維持應用程式產品組合up-to-date檢視，我們建議為工作負載探索使用專門的工具。

部署探索工具 – 在適用的情況下，採購、安裝和設定探索工具，並建立推展計劃到目標系統。所有目標系統兩週的程式設計資料收集可提供足夠的資料，以達到此階段的結果。不過，若要精簡輸出，在稍後階段需要持續收集資料。

收集總體擁有成本 (TCO) 資料 – 使用收集的資料來產生和更新 TCO 報告，並建立具方向性的商業案例。如需詳細資訊，請參閱最佳實務一節。

使用應用程式合理化模型 – 建立或採用基礎應用程式合理化模型以進行遷移。根據 6 Rs 決策樹，包含關鍵應用程式屬性、優先順序權重和初始 R 類型 （重寫、轉換、重構 （重新建構）、重新購買、保留、淘汰） 的選擇。

識別初始遷移候選項目 – 現在可移動哪些應用程式來建立或擴展 AWS 基礎並取得經驗？ 在此階段，模型應該優先考慮具有低層級相依性的簡單工作負載 （例如零三）。 

規劃持續評估 – 規劃下一個產品組合評估活動，例如執行優先順序工作負載的詳細評估。

計劃通訊 – 為您的利益相關者建立通訊計劃或節奏，以及範圍控制機制。範圍隨著遷移計畫進行而變更是正常的。確保產品組合資料有單一的事實來源，並且會追蹤、評估和傳達範圍的變更。

記錄的業務驅動因素、成果、目標和技術指導原則。

應用程式和基礎設施的初始清查，以及已識別的資料差距。這是產品組合的初始檢視，這些產品組合將在後續階段中反覆運算和微調。

有方向性的商業案例和要遷移的估計成本。

三五個初始遷移候選應用程式的清單。

產品組合相關活動、里程碑和範圍變更的通訊計劃。

專注於階段目標，並將分析保持在高層級。採用漸進式的資料收集方法，在繼續之前，請不要等待完整的資料集。

避免分析癱瘓。專注於識別資料差距和驅動動作來縮小這些差距。

採購專門的探索工具。通常透過自動化工具取得的程式設計資料具有更高層級的信任，在撰寫文件、靜態資料和機構知識之前應優先考慮。

使用已識別的利益相關者來移除封鎖程式。

將單執行緒領導者指派給應用程式產品組合評估工作流程。

請考慮將 Migration Evaluator 用於定向商業案例，或探索 AWS Partner Network 工具和 TCO 和 AWS 定價方案。

請考慮 AWS 專業服務和 AWS 合作夥伴，以協助您加速業務成果。