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

# 探索加速和初始規劃
<a name="portfolio-discovery-initial-planning"></a>

產品組合評估的第一階段著重於在產品組合層級取得和分析資料的初始步驟。主要目標是識別業務驅動因素，並從應用程式和基礎設施收集一般資料，以取得產品組合的初始檢視。此資料包含高階技術和業務屬性，例如應用程式名稱、環境、產品版本、重要性、效能值等，如[資料需求](understanding-initial-assessment-data-requirements.md)一節中所述。完成此階段是了解專案範圍、識別初始遷移候選項目，以及通知商業案例的關鍵。

## 此階段的主要結果
<a name="discovery-outcomes"></a>
+ 記錄的業務驅動因素、成果、目標和技術指導原則。
+ 應用程式和基礎設施的初始庫存，以及已識別的資料差距。這是產品組合的初始檢視，這些產品組合將在後續階段進行反覆運算和改進。
+ 有方向性的商業案例和要遷移的預估成本。
+ 初始遷移候選項目的清單 （例如，三五個應用程式）。
+ 定義後續步驟。

# 了解初始評估資料需求
<a name="understanding-initial-assessment-data-requirements"></a>

當無法清楚了解需要哪些資料以及何時需要資料時，資料收集可能需要大量的時間，並輕鬆成為封鎖程式。關鍵在於了解什麼太少和什麼太多資料與此階段結果之間的平衡。若要專注於此早期產品組合評估所需的資料和逼真度層級，請採用反覆方法來收集資料。

## 資料來源和資料需求
<a name="data-sources-data-requirements"></a>

第一步是識別您的資料來源。從識別組織內可滿足資料需求的關鍵利益相關者開始。這些通常是服務管理、操作、容量規劃、監控和支援團隊以及應用程式擁有者的成員。使用這些群組的成員建立工作工作階段。傳達資料需求，並取得可提供資料的工具和現有文件清單。

若要引導這些對話，請使用下列一組問題：
+ 目前的基礎設施和應用程式庫存有多準確和最新？ 例如，對於公司組態管理資料庫 (CMDB)，我們是否已經知道差距在哪裡？
+ 我們是否有讓 CMDB （或同等項目） 保持更新的作用中工具和程序？ 若是如此，更新的頻率為何？ 最新的重新整理日期是什麼？
+ 目前的庫存，例如 CMDB，是否包含application-to-infrastructure映射？ 每個基礎設施資產是否都與應用程式相關聯？ 每個應用程式是否映射至基礎設施？
+ 清查是否包含每個產品的授權和授權合約目錄？
+ 清查是否包含相依性資料？ 請注意是否存在通訊資料，例如伺服器對伺服器、應用程式對應用程式、應用程式或伺服器對資料庫。
+ 環境中還有哪些其他工具可以提供應用程式和基礎設施資訊？ 請注意，存在可做為資料來源的效能、監控和管理工具。
+ 託管應用程式和基礎設施的不同位置有哪些，例如資料中心？

回答這些問題之後，請列出已識別的資料來源。然後將擬真度或信任層級指派給每個層級。最近 (30 天內） 從作用中的程式設計來源驗證的資料，例如工具，具有最高的保真度。靜態資料被視為低保真度和較不信任。靜態資料的範例包括文件、工作手冊、手動更新的 CMDBs或任何其他非程式設計維護的資料集，或是上次重新整理日期超過 60 天。

下表提供的資料逼真度層級做為範例。我們建議您根據對假設的最大容忍度和相關聯的風險來評估組織的需求，以確定什麼是適當的保真度等級。在表格中，機構知識是指有關未記錄的應用程式和基礎設施的任何資訊。


| **資料來源** | **富達水準** | **產品組合涵蓋範圍** | **評論** | 
| --- |--- |--- |--- |
| 機構知識 | 低 - 高達 25% 的準確資料、75% 的假設值或資料超過 150 天。 | 低 | 稀少，專注於關鍵應用程式 | 
| 知識庫 | 中低 - 35-40% 的準確資料、65-60% 的假設值或資料為 120-150 天。 | 中 | 手動維護、不一致的細節層級 | 
| CMDB | 中 - \$150% 的準確資料、\$150% 的假設值或資料為 90-120 天。 | 中 | 包含混合來源的資料、數個資料差距 | 
| VMware vCenter 匯出 | 中高 - 75-80% 的準確資料、25-20% 的假設值或資料為 60-90 天。 | 高 | 涵蓋 90% 的虛擬化資產 | 
| 應用程式效能監控 | 高 - 大部分準確的資料，約 5% 的假設值或資料為 0-60 天。 | 低 | 僅限關鍵生產系統 （涵蓋應用程式產品組合的 15%) | 

下表指定每個資產類別 （應用程式、基礎設施、網路和遷移）、特定活動 （庫存或商業案例） 的必要和選用資料屬性，以及此評估階段的建議資料逼真度。資料表使用以下縮寫：
+ R，針對必要
+ (D)，用於定向商業案例，需要總體擁有成本 (TCO) 比較和定向商業案例
+ (F)，適用於全向商業案例，TCO 比較和包含遷移和現代化成本的定向商業案例需要
+ O，用於選用
+ N/A，適用於 不適用

**應用程式**


| **屬性名稱** | **描述** | **庫存和優先順序** | **商業案例** | **建議的逼真度等級 （最低）** | 
| --- |--- |--- |--- |--- |
| 唯一識別符 | 例如，應用程式 ID。通常適用於現有的 CMDBs或其他內部庫存和控制系統。每當組織中未定義 ID 時，請考慮建立唯一的 IDs。 | R | R (D) | 高 | 
| Application name (應用程式名稱) | 您的組織已知此應用程式的名稱。適用時包括商用off-the-shelf(COTS) 廠商和產品名稱。 | R | R (D) | 中高 | 
| 是 COTS 嗎？ | 是或否。無論是商業應用程式還是內部開發 | R | R (D) | 中高 | 
| COTS 產品和版本 | 商業軟體產品名稱和版本  | R | R (D) | 中 | 
| Description | 主要應用程式函數和內容 | R | O | 中 | 
| 重要性 | 例如，策略或產生收入的應用程式，或支援關鍵 函數 | R | O | 中高 | 
| Type | 例如，資料庫、客戶關係管理 (CRM)、Web 應用程式、多媒體、IT 共用服務 | R | O | 中 | 
| Environment | 例如，生產、生產前、開發、測試、沙盒 | R | R (D) | 中高 | 
| 合規與法規 | 適用於工作負載的架構 （例如 HIPAA、SOX、PCI-DSS、ISO、SOC、FedRAMP) 和法規要求 | R | R (D) | 中高 | 
| 相依性 | 對內部和外部應用程式或服務的上游和下游相依性。非技術相依性，例如操作元素 （例如維護週期） | O | O | 中低 | 
| 基礎設施映射 | 映射到組成應用程式的實體和/或虛擬資產 | O | O | 中 | 
| 授權 | 商品軟體授權類型 （例如 Microsoft SQL Server Enterprise) | O | R | 中高 | 
| Cost | 軟體授權、軟體操作和維護的成本 | N/A | O | 中 | 

**基礎設施**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **屬性名稱** | **描述** | **庫存和優先順序** | **商業案例** | **建議的逼真度等級 （最低）** | 
| 唯一識別符 | 例如，伺服器 ID。通常適用於現有的 CMDBs或其他內部庫存和控制系統。每當組織中未定義 ID 時，請考慮建立唯一的 IDs。 | R | R | 高 | 
| 網路名稱 | 網路中的資產名稱 （例如主機名稱） | R | O | 中高 | 
| DNS 名稱 （完整網域名稱，或 FQDN) | DNS 名稱 | O | O | 中 | 
| IP 地址和網路遮罩 | 內部和/或公有 IP 地址 | R | O | 中高 | 
| 資產類型設定 | 實體或虛擬伺服器、Hypervisor、容器、裝置、資料庫執行個體等。 | R | R | 中高 | 
| 產品名稱 | 商業廠商和產品名稱 （例如 VMware ESXi、IBM Power Systems、Exadata) | R | R | 中 | 
| 作業系統 | 例如，REHL 8、Windows Server 2019、AIX 6.1 | R | R | 中高 | 
| Configuration | 配置的 CPU、核心數量、每個核心的執行緒、總記憶體、儲存、網路卡 | R | R | 中高 | 
| 使用率 | CPU、記憶體和儲存峰值和平均值。資料庫執行個體輸送量。 | R | O | 中高 | 
| 授權 | 商品授權類型 （例如 RHEL Standard) | R | R | 中 | 
| 是共用基礎設施嗎？ | 是或否表示提供共用服務的基礎設施服務，例如身分驗證提供者、監控系統、備份服務和類似服務 | R | R (D) | 中 | 
| 應用程式映射 | 在此基礎設施中執行的應用程式或應用程式元件 | O | O | 中 | 
| Cost | 裸機伺服器的完全負載成本，包括硬體、維護、操作、儲存 (SAN、NAS、物件）、作業系統授權、機架空間共用和資料中心額外負荷 | N/A | O | 中高 | 

**網路**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **屬性名稱** | **描述** | **庫存和優先順序** | **商業案例** | **建議的逼真度等級 （最低）** | 
| 管道大小 (Mb/s)、備援 (Y/N) | 目前的 WAN 連結規格 （例如，1000 Mb/s 備援） | O | R | 中 | 
| 連結使用率 | 尖峰和平均使用率、傳出資料傳輸 (GB/月） | O | R | 中 | 
| 延遲 （毫秒） | 連線位置之間的目前延遲。 | O | O | 中 | 
| Cost | 每月的目前成本 | N/A | O | 中 | 

**移轉**


|  |  |  |  |  | 
| --- |--- |--- |--- |--- |
| **屬性名稱** | **描述** | **庫存和優先順序** | **商業案例** | **建議的擬真度等級 （最低）** | 
| 重新託管 | 每個工作負載 （人員日） 的客戶和合作夥伴工作量、客戶和合作夥伴每天成本、工具成本、工作負載數量 | N/A | R (F) | 中高 | 
| 平台重建 | 每個工作負載 （人員日） 的客戶和合作夥伴工作量、每天的客戶和合作夥伴成本、工作負載數量 | N/A | R (F) | 中高 | 
| 重構 | 每個工作負載 （人員日） 的客戶和合作夥伴工作量、每天的客戶和合作夥伴成本、工作負載數量 | N/A | O | 中高 | 
| 淘汰 | 伺服器數量、平均除役成本 | N/A | O | 中高 | 
| 登陸區域 | 重複使用現有的 （是/否）、所需的 AWS 區域清單、成本 | N/A | R (F) | 中高 | 
| 人員和變更 | 要在雲端營運和開發中訓練的員工人數、每個人的訓練成本、每個人的訓練時間成本 | N/A | R (F) | 中高 | 
| 持續時間 | 範圍內工作負載遷移的持續時間 （月） | O | R (F) | 中高 | 
| 平行成本 | 在遷移期間可以移除現狀成本的時間範圍和速率 | N/A | O | 中高 | 
| 在遷移期間引入 AWS 產品和服務和其他基礎設施成本的時間範圍和速率 | N/A | O | 中高 | 

## 評估探索工具的需求
<a name="discovery-tooling"></a>

您的組織是否需要探索工具？ 產品組合評估需要有關應用程式和基礎設施的高可用性、up-to-date資料。產品組合評估的初始階段可以使用假設來填補資料差距。

不過，隨著進度的進行，高保真度資料可讓您建立成功的遷移計劃，並正確估算目標基礎設施，以降低成本並最大化效益。它還透過啟用考慮相依性的實作並避免遷移陷阱來降低風險。雲端遷移計劃中探索工具的主要使用案例，是透過下列方式降低風險並提高資料的可信度：
+ 自動化或程式設計資料收集，產生經過驗證、高度信任的資料
+ 加速取得資料的速率，改善專案速度並降低成本
+ 資料完整性層級增加，包括 CMDBs 中通常不提供的通訊資料和相依性
+ 取得洞見，例如自動化應用程式識別、TCO 分析、預計執行率和最佳化建議
+ 高可信度遷移波規劃

當不確定系統是否存在於指定位置時，大多數探索工具可以掃描網路子網路，並探索回應 ping 或簡易網路管理通訊協定 (SNMP) 請求的系統。請注意，並非所有網路或系統組態都會允許 ping 或 SNMP 流量。與您的網路和技術團隊討論這些選項。

應用程式產品組合評估和遷移的後續階段高度依賴準確的相依性映射資訊。相依性映射可讓您了解 所需的 AWS 基礎設施和組態 （例如安全群組、執行個體類型、帳戶配置和網路路由）。它也有助於將必須同時移動的應用程式分組 （例如必須透過低延遲網路通訊的應用程式）。此外，相依性映射提供不斷發展的商業案例資訊。

決定探索工具時，請務必考慮評估程序的所有階段，並預測資料需求。資料差距可能會成為封鎖程式，因此透過分析未來的資料需求和資料來源來預測這些漏洞至關重要。欄位中的經驗指出，大多數停滯的遷移專案具有有限的資料集，其中範圍內的應用程式、相關聯的基礎設施及其相依性無法明確識別。這種缺乏識別可能會導致不正確的指標、決策和延遲。取得up-to-date資料是成功遷移專案的第一步。

*如何選取探索工具？*

市場上的數種探索工具提供不同的功能和功能。考慮您的需求。並決定最適合您組織的選項。決定遷移的探索工具時最常見的因素如下：

*安全性*
+ 存取工具資料儲存庫或分析引擎的身分驗證方法是什麼？ 
+ 誰可以存取資料，以及存取工具的安全控制是什麼？ 
+ 工具如何收集資料？ 是否需要專用登入資料？ 
+ 工具需要哪些登入資料和存取層級才能存取我的系統並取得資料？ 
+ 如何在工具元件之間傳輸資料？ 
+ 工具是否支援靜態和傳輸中的資料加密？ 
+ 資料是否集中在我的環境內外的單一元件中？ 
+ 什麼是網路和防火牆需求？ 

確保安全團隊參與有關探索工具的早期對話。

*資料主權*
+ 資料的存放和處理位置為何？ 
+ 工具是否使用軟體即服務 (SaaS) 模型？ 
+ 是否可能將所有資料保留在我的環境範圍內？ 
+ 資料可以在離開組織邊界之前進行篩選嗎？ 

根據資料駐留需求來考慮您的組織需求。

*架構*
+ 需要哪些基礎設施，以及有哪些不同的元件？
+ 是否有多個架構可用？ 
+ 工具是否支援在空氣鎖定的安全區域中安裝元件？

*效能*
+ 資料收集對我的系統有何影響？ 

*相容性和範圍*
+ 此工具是否支援我的所有或大部分產品和版本？ 檢閱工具文件，根據有關範圍的目前資訊驗證支援的平台。
+ 我大部分的作業系統是否支援資料收集？ 如果您不知道作業系統版本，請嘗試將探索工具清單縮小為支援範圍更廣的系統。

*收集方法*
+ 工具是否需要在每個目標系統上安裝 代理程式？
+ 它是否支援無代理程式部署？ 
+ 客服人員和無客服人員是否提供相同的功能？ 
+ 什麼是收集程序？

*功能*
+ 有哪些可用的功能？ 
+ 是否可以計算總擁有成本 (TCO) 和預估 AWS 雲端 執行率？ 
+ 它是否支援遷移規劃？ 
+ 它是否測量效能？ 
+ 它是否可以建議目標 AWS 基礎設施？ 
+ 它是否執行相依性映射？ 
+ 它提供什麼層級的相依性映射？ 
+ 它是否提供 API 存取？（例如，是否可以以程式設計方式存取它來取得資料？)

考慮具有強大應用程式和基礎設施相依性映射函數的工具，以及可以從通訊模式推斷應用程式的工具。

*成本*
+ 什麼是授權模型？ 
+ 授權的費用是多少？ 
+ 是每個伺服器的定價嗎？ 是否為分層定價？ 
+ 是否有任何功能有限的選項可以隨需授權？ 

探索工具通常會在整個遷移專案生命週期中使用。如果您的預算有限，請考慮至少 6 個月。不過，缺少探索工具通常會導致更高的手動工作量和內部成本。

*支援模型*
+ 預設會提供哪些層級的支援？ 
+ 是否有任何可用的支援計畫？ 
+ 事件回應時間為何？

*專業服務*
+ 供應商是否提供專業服務來分析探索輸出？ 
+ 它們可以涵蓋本指南的元素嗎？ 
+ 工具 \$1 服務是否有任何折扣或套件？

**提示**  
若要尋找和評估探索工具，請使用[探索、規劃和建議](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/)網站。

*探索工具的建議功能*

為了避免隨著時間的推移佈建和合併來自多個工具的資料，探索工具應涵蓋下列最低功能：
+ **軟體** – 探索工具應該能夠識別執行中的程序和已安裝的軟體。
+ **相依性映射** – 它應該能夠收集網路連線資訊，並建置伺服器和執行中應用程式的傳入和傳出相依性映射。此外，探索工具應該能夠根據通訊模式從基礎設施群組推斷應用程式。
+ **設定檔和組態探索** – 它應該能夠報告基礎設施設定檔，例如 CPU 系列 （例如 x86、PowerPC)、CPU 核心數量、記憶體大小、磁碟數量和大小，以及網路介面。
+ **網路儲存探索** – 它應該能夠從網路連接儲存 (NAS) 偵測和描述網路共用。
+ **效能** – 它應該能夠報告 CPU、記憶體、磁碟和網路的峰值和平均使用率。
+ **差距分析** – 它應該能夠提供有關資料數量和保真度的洞察。
+ **網路掃描** – 它應該能夠掃描網路子網路並探索未知的基礎設施資產。
+ **報告** – 它應該能夠提供收集和分析狀態。
+ **API 存取** – 它應該能夠提供以程式設計方式存取收集的資料。

*要考慮的其他功能*
+ **TCO 分析**可提供目前現場部署成本和預計 AWS 成本之間的成本比較。
+ 在重新託管和轉換案例中，Microsoft SQL Server 和 Oracle 系統的**授權分析和最佳化建議**。
+ **遷移策略建議** （探索工具是否可以根據目前的技術提出預設遷移 R 類型建議？)
+ **庫存匯出** （至 CSV 或類似格式）
+ **正確調整大小的建議 **（例如，它是否可以對應建議的目標 AWS 基礎設施？)
+ **相依性視覺化** （例如，是否可以在圖形模式中視覺化相依性映射？)
+ **架構檢視** （例如，是否可以自動產生架構圖？)
+ **應用程式優先順序 **（是否可以為應用程式和基礎設施屬性指派權重或相關性，以建立遷移的優先順序條件？)
+ **波浪規劃** （例如，建議的應用程式群組和建立遷移波浪計劃的能力）
+ **遷移成本估算 **（遷移的工作量估算）

*部署考量*

在您選取並取得探索工具之後，請考慮下列問題，以推動與負責在組織中部署工具的團隊進行對話：
+ 伺服器或應用程式是否由第三方操作？ 這可能會要求團隊參與並遵循程序。
+ 取得部署探索工具的核准之高階程序是什麼？
+ 存取伺服器、容器、儲存和資料庫等系統的主要身分驗證程序是什麼？ 伺服器登入資料是本機還是集中式？ 取得登入資料的程序為何？ 需要登入資料才能從您的系統收集資料 （例如容器、虛擬或實體伺服器、Hypervisor 和資料庫）。為探索工具取得憑證以連線至每個資產可能具有挑戰性，尤其是當這些資產未集中時。
+ 什麼是網路安全區域大綱？ 網路圖表是否可用？
+ 在資料中心請求防火牆規則的程序是什麼？
+ 與資料中心操作 （探索工具安裝、防火牆請求） 相關的目前支援服務層級協議 (SLAs) 是什麼？

# 業務驅動因素和技術指導方針
<a name="business-drivers-technical-guiding-principles"></a>

## 商業驅動程式
<a name="business-drivers"></a>

無論您的組織是否已決定移至雲端或接近該決策，定義和記錄雲端遷移的商業驅動因素都會釐清遷移的原因。記錄原因之後，您可以定義要遷移的內容及其遷移方式。此活動很重要。我們建議您儘早在程序中進行，以通知和引導後續步驟。

識別應參與討論的利益相關者，以記錄驅動因素。一般而言，組織中CxOs、資深經理和關鍵技術領導者，以及您自己的客戶。雖然您的客戶不太可能參與此次討論，但我們建議您組織中指定一或多個人員來代表客戶的觀點和目標。

業務驅動因素應連結至指標，該指標可在遷移過程中測量，以驗證是否已實現結果。公司的策略目標和年度報告可以做為起點。

根據現有和預測的指標，將對話重點放在公司希望達到的目標，因為轉移到雲端。考慮目標和業務成果。此外，考慮隨著雲端採用率的增加，成功是什麼樣子。

接著，為每個驅動程式建立重要性層級。優先順序為何？ 預期的效益是什麼？ 好處如何支援業務目標和成果？ 在應用程式產品組合評估的情況下，答案將有助於排定遷移工作負載的優先順序，並建立技術指導原則。不過，業務驅動因素將定義和影響整個遷移計畫。

## 技術指導原則
<a name="technical-guiding-principles"></a>

技術指導原則會在產品組合評估的後期階段通知遷移策略選擇。在目前階段，重點是識別它們。

指導原則可以建立為衍生自業務目標和成果的一般技術相關和方法相關決策。

例如，公司的主要目標是降低成本，所需成果是在 6-12 個月內在特定日期之前關閉內部部署資料中心。產生的引導原則是盡可能使用重新託管或重新放置遷移策略，將所有應用程式提升並轉移至雲端。在這種情況下，lift-and-shift方法可加速短期遷移結果。應用程式移出內部部署資料中心後，公司可以專注於主要業務驅動因素，以最佳化或現代化遷移的工作負載。

若要建立技術指導原則，請先分析業務驅動因素。識別將實現業務目標和成果的技術和技術清單。接著，精簡清單，並根據適用性或偏好指派相關性順序，以達到所需的結果。

記錄並傳達指導原則給參與規劃和執行遷移的人員。強調原則與實際實作之間的疑慮和潛在衝突。

下表提供商業驅動因素和技術指導原則的範例。


| **商業驅動程式** | **結果** | **指標** | **技術指導原則** | 
| --- |--- |--- |--- |
| 加速創新。 | 提高競爭性、提高業務敏捷性 | 每天或每月部署次數、每季發佈的新功能、客戶滿意度分數、實驗次數 | 透過使用微服務和 DevOps 操作模型來重新考慮區分應用程式，以提高敏捷性和新功能的上市速度。 | 
| 降低營運和基礎設施成本。 | 符合的供需彈性成本基礎 （為您的使用量付費） | 隨時間變化的支出 | 1. 使用適當調整基礎設施大小來重新託管應用程式。2. 淘汰低使用率或沒有使用率的應用程式。 | 
| 提高操作彈性。 | 改善運作時間，縮短復原的平均時間 | SLAs、事件數量 | 1. 將應用程式轉換為最新且最佳支援的作業系統版本。2. 為關鍵應用程式實作高可用性架構。 | 
| 離開資料中心。 | 資料中心在 6–12 個月內關閉的日期 | 伺服器遷移的速度 | 使用 Cloud Migration Factory Solution 來重新託管應用程式。 | 
| 留在內部部署，但增加敏捷性和彈性。 | 改善現場部署時的競爭性和運作時間 | 每天或每月部署次數、每季新功能發行次數、SLAs、事件數量 | 1. 透過將系統功能擴展到雲端來現代化系統。2. 評估 的重新託管或轉譯 AWS Outposts。 | 

# 啟動資料收集
<a name="initiating-data-collection"></a>

資料收集是從應用程式和基礎設施收集中繼資料的程序。此程序會在評估的所有階段反覆進行。在每個階段中，資料數量和保真度都會增加。在這個階段，重點是收集可協助建立初始庫存的一般資料。清查將用於建立定向商業案例和識別初始遷移候選項目。

識別目前的資料來源之後，建議您盡可能多地從系統收集資訊。如需詳細資訊，請參閱此階段[的資料需求](understanding-initial-assessment-data-requirements.md)。

此方法有助於更新目前的產品組合檢視，以及組織對其應用程式和服務的知識。它也有助於判斷要移動的目標。建議的方法為檢閱現有資料，例如組態管理資料庫 (CMDB) 輸出和資訊技術服務管理 (ITSM) 系統。然後建構以資料收集為目標的資產清單。如果您的組織完全清楚遷移範圍內和範圍外的內容，您可以將資料收集限制在範圍內的系統。

建置產品組合時，請考慮應用程式及其環境或軟體版本生命週期。例如，不識別客戶關係管理 (CRM) 應用程式並指定其具有測試、開發和生產環境，而是列出三個應用程式 （例如 CRM-Test、CRM-Dev、CRM-Prod)。或者，使用 CRM 名稱，但為每個環境指派唯一的 ID，並在資料儲存庫中以個別記錄呈現。這將有助於個別規劃和追蹤這些環境的遷移。例如，您可能想要先遷移非生產環境。透過根據環境列出應用程式的執行個體，您可以清楚管理和控管其轉換。

在資料收集期間，可能不確定哪些應用程式或伺服器位於指定的資料中心或來源位置。在這些情況下，從現有的管理工具取得裸機和 Hypervisor 清單很有幫助。例如，您可以連線至 Hypervisor，以取得要以資料收集為目標的虛擬機器清單。

請注意，在合併現有資料來源時，初始輸出可能不完整。關鍵在於針對此階段[的資料需求](understanding-initial-assessment-data-requirements.md)，以及可從現有來源取得的內容，執行差距分析。請務必將完整性百分比與資料逼真度進行對比。來自低保真度來源的較高完整性層級將包含數個可能導致分析瑕疵的假設。雖然此評估階段不需要最大資料保真度，但我們建議資料來源至少為中至中高保真度。將這些數字與組織的風險承受能力進行比較，包括使用假設填補資料差距。

差距分析可協助您了解正在使用的資料數量和品質。分析也可協助您建立必須做出的假設層級，以建立有方向性的商業案例，並排定應用程式遷移的優先順序。探索工具有助於填補差距並收集高逼真度資料。為了提高資料的可信度層級並加速遷移結果，建議您儘早部署探索工具。早期行動也很重要，因為新工具的內部採購、安全和實作程序可能需要幾週或幾個月才能完成。

我們建議在此階段建立通訊計畫或節奏，以及範圍變更控制機制。這可協助您隨時通知利益相關者，讓他們可以事先規劃並降低風險。明確通訊的關鍵元素是定義應用程式產品組合和相關聯基礎設施的單一事實來源。避免保留多個記錄系統和應用程式和基礎設施清單。將資料保留在支援版本控制和線上協同合作的單一位置 （例如資料庫、工具或試算表），並將擁有者指派給該位置。

# 優先順序和遷移策略
<a name="prioritization-and-migration-strategy"></a>

遷移規劃的關鍵元素是建立優先順序條件。本練習的重點是了解應用程式遷移的順序。策略是採取反覆且漸進的方法，以發展優先順序模型。

## 排定應用程式的優先順序
<a name="prioritizing-applications"></a>

此評估階段著重於建立初始條件，以排定低風險和低複雜度工作負載的優先順序。這些工作負載是試行應用程式的良好候選項目。在初始遷移中使用低風險、低複雜度工作負載可降低風險，並讓團隊有機會獲得體驗。這些條件將在進一步的評估階段發展，以在建立遷移波動計畫時與業務驅動因素保持一致的優先順序。

初始條件應優先考慮具有少量相依性的應用程式、在雲端支援的基礎設施中執行，以及來自非生產環境的應用程式。例如，具有 0-3 個相依性的應用程式已準備好在開發或測試環境中重新託管。根據雲端採用成熟度和可信度層級，這些條件對於定義試行應用程式以及可能的第一和第二遷移波有效。

*決定要使用的初始條件*

選取要用於排定第一個工作負載優先順序的 2-10 個資料點。這些資料點來自您的初始應用程式和基礎設施庫存 （請參閱[資料收集](initiating-data-collection.md)一節）。

接著，為每個資料點的每個可能值定義分數或權重。例如，如果選取環境屬性，並且可能的值是生產、開發和測試，則每個值都會獲得一個分數，數字越大，表示優先順序越高。雖然這是選用的，但我們建議您為每個資料點的重要性或相關性指派乘數。這個選用步驟提供更高層級的差異性，以強調更重要的項目，這有助於在您反覆將分數指派給值時保持條件的一致性。

根據為前幾個遷移波排定低風險、簡單應用程式優先順序的策略，下表顯示範例屬性選擇及其值指派。


| **屬性 （資料點）** | **可能的值** | **分數 (0-99)** | **重要性或相關性乘數** | 
| --- |--- |--- |--- |
| Environment | 測試 | 60 | 高 (1x) | 
| 開發 | 40 | 
| 生產 | 20 | 
| 業務關鍵性 | 低 | 60 | 高 (1x) | 
| 中 | 40 | 
| 高 | 20 | 
| 法規或合規架構 | 無 | 60 | 高 (1x) | 
| FedRAMP | 10 | 
| 作業系統支援 | 雲端就緒 | 60 | 中高 (0.8x) | 
| 雲端不支援 | 10 | 
| 運算執行個體的數量 | 1-3 | 60 | 中高 (0.8x) | 
| 4-10 | 40 | 
| 11 個或更多 | 20 | 
| 遷移策略 | 重新託管 | 70 | 中型 (0.6x) | 
| 平台重建 | 30 | 
| 重構或重新架構 | 10 | 

請確定您選取的屬性可以做為應用程式之間的關鍵差異。否則，這些條件將導致許多工作負載共用相同的優先順序。套用模型後，建議您查看結果排名的頂端和底部，以查看您是否同意。如果您通常不同意，您可以重新檢視用於對工作負載進行評分的條件。

在您取得排名後，請查看整個產品組合的分數分佈。分數本身並不重要。這是重要的分數之間的差異。例如，您可能會發現最高總分為 8，000，最低分數為 800。考慮將產生的分數繪製為長條圖，以便您可以驗證您是否具有良好的分佈。理想的分佈看起來像標準鐘形曲線，具有幾個非常高優先順序的工作負載和幾個非常低優先順序的工作負載。大多數應用程式將位於中間的某個位置。

初始優先順序的另一個關鍵方面是包含內部團隊或業務單位，這些團隊或業務單位對成為雲端的早期採用者表示興趣。這些可能是取得商業支援以遷移指定應用程式的重要手段，特別是在早期。如果您的組織發生這種情況，請在上表中包含業務單位屬性。為願意轉發其應用程式的業務單位提供高分。使用業務單位屬性有助於將這些應用程式排在清單頂端。

同意產生的排名後，請選取前 5-10 個應用程式。這些將是您初始的應用程式遷移候選項目。精簡清單，以確認 3-5 個應用程式。這可協助您在執行詳細的應用程式評估時採取有針對性的方法。如需詳細資訊，請參閱[優先應用程式評估](prioritized-applications-assessment.md)。

 

## 判斷遷移的 R 類型
<a name="migration-r-type"></a>

決定每個應用程式和相關基礎設施的遷移策略，將會影響遷移速度、成本和效益層級。這是根據平衡的因素組合來確定策略的關鍵，包括業務驅動因素、技術指導原則、優先順序標準和業務策略。

有時，這些因素會產生衝突的觀點。例如，遷移的主要驅動因素可能是創新和敏捷性。同時，您可能需要快速降低成本。現代化範圍內的所有應用程式，將可降低長期執行的成本，但需要更大量的前期投資。在這種情況下，一種方法是使用較不費力的策略來遷移應用程式，例如重新託管或轉譯。這可以在短期內提供快速的效率和降低成本。然後，在稍後階段重新投資節省的成本來現代化應用程式，並進一步降低成本。

不過，從完全重新託管所有應用程式開始，會延遲現代化所帶來的更大優勢。關鍵是尋找遷移策略之間的平衡，以便商業策略應用程式優先進行現代化，而其他應用程式可以先重新託管或重新格式化，然後再進行現代化。

*如何判斷應用程式的遷移策略？*

在此評估階段，重點是納入引導遷移策略選擇的初始模型。若要驗證初始應用程式的遷移策略，請搭配業務驅動因素和優先順序條件使用模型。決策樹的預設邏輯將協助您判斷範圍的初始處理方式。在樹狀目錄中，最複雜的方法，例如重構或重新架構，會保留給您的策略工作負載。

![\[本指南討論的 6 R 決策程序。\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/application-portfolio-assessment-guide/images/6Rs-DecisionTree-baseModel.png)


此圖表的可自訂 [draw.io](https://github.com/jgraph/drawio-desktop/releases) 版本可在*[附件](#attachments)*區段中取得。

初始模型的第一步是將樹狀結構頂端的業務驅動程式更新為組織定義的業務驅動程式。接著，將樹狀結構套用至應用程式元件，而非整個應用程式。例如，如果三層應用程式有三個元件 （前端、應用程式層和資料庫），則每個元件都應獨立傳輸樹狀目錄，並獲指派特定的策略和模式。這是因為在某些情況下，您可能想要重新託管或轉換指定的層，並重構 （重新架構） 其他層。

獨立元件指派將引導您定義相關聯基礎設施的遷移策略。基礎設施策略可能與其支援的應用程式元件具有相同的策略，也可能不同。例如，將複寫到具有較新作業系統的新虛擬機器中的應用程式元件將遵循複寫策略，而託管它的目前虛擬機器將被淘汰。基礎設施的遷移策略是根據為應用程式元件選擇的策略來計算。

使用決策樹來建立遷移策略之前，請使用幾個應用程式測試邏輯，並查看您是否通常同意結果。6 Rs 決策樹是一份指南，不會取代判斷其正確性所需的分析。樹狀結構邏輯可能不適用於特定案例。將這些案例視為例外狀況，並透過記錄覆寫的原理來覆寫樹狀結構驅動的決策，而不是變更樹狀結構邏輯。這可防止多個決策樹版本，這可能會變得難以管理。一般指引是樹狀結構在工作負載中應至少 70-80% 有效。其餘部分則會有例外狀況。在此評估階段，對樹狀結構邏輯的任何調整都應專注於建立初始模型。進一步的反覆運算和精簡會在稍後階段進行，例如[產品組合分析和遷移規劃](portfolio-analysis-migration-planning.md)。

## 附件
<a name="attachments"></a>

[attachment.zip](samples/attachment.zip)

# 建立定向商業案例
<a name="directional-business-case"></a>

來自整個企業的利益相關者應了解和接受業務案例，以在整個過程中轉換每個步驟。

在早期階段，快速從遷移計畫顯示足夠的潛在價值非常重要，這樣您就可以保護規劃和建立計畫所需的資源。具方向性的商業案例旨在透過可及早收集的有限資料，提供合理可信度來實現令人信服的商業價值。

建立計畫後，會進一步開發商業案例。詳細案例提供更高的準確性、更完整的程式值，以及對規劃優先順序的洞察。它會定義和量化組織所購買的計劃業務成果，並設定您的計劃控管辦公室可以引導計劃並衡量其成就的基準。

## 修正定向商業案例的範圍
<a name="fix-scope"></a>

方向性商業案例通常會在 2-4 週內快速組合。它需要產生足夠的可信度，以便您可以保護資源以建立核心團隊、在需要時與 AWS 合作夥伴互動，以及至少完成[優先應用程式評估](prioritized-applications-assessment.md)、[產品組合分析和遷移規劃](portfolio-analysis-migration-planning.md)階段。

一般而言，支援產品組合遷移的方向性商業案例會建立為下列其中一項：
+ 隨需基礎設施環境與遷移後 AWS 服務 架構之間的簡單*總擁有成本 (TCO)*** **比較。此比較顯示指定工作負載磁碟區的預期執行率差異。
+ 商業案例** **，顯示遷移至 AWS 包含遷移成本與保持原狀的淨現值 (NPV)、投資報酬率 (ROI)、償還期、修改後內部報酬率 (MIRR) 和 3–5 年現金流分析。

方向性商業案例範圍通常僅限於下列其中一項：
+ 基礎設施技術成本的比較
+ 基礎設施技術和操作成本的比較

一般而言，產品組合越大，案例需要的開發程度就越少。這是因為可以做出更廣泛的假設，而不會顯著影響結果。對於較小的產品組合，任何變更都會產生更大的影響，因此需要更多詳細資訊。

首先建立基礎基礎設施成本比較。然後決定比較是否足夠吸引人，再繼續。通常，超過 400 部伺服器的產品組合會在 3 年操作內， AWS或 5 年內 250 部伺服器，單獨顯示基礎設施成本降低的正面商業案例，但這可能會有所不同。對於較小的產品組合，可能需要更多詳細資訊。

相反地，在此階段檢查其他商業價值元件很少有用，例如衍生自改善彈性或業務敏捷性的值，除非遷移範圍總計少於約 5 個工作負載或 50 個伺服器。

## 焦點值驅動因素
<a name="focus-value-drivers"></a>

基礎設施技術 TCO 比較會將現狀基礎設施成本的模型與執行工作負載所需的基本物料 AWS 服務 清單模型進行比較，並具有同等的效能和可用性。您可以完成許多最佳化。不過，在此階段，重點在於下列清單，因為它們更容易評估，而且通常會節省約 30% 的 TCO，這足以繼續：
+ **運算彈性** – 將用量不是 100% 的伺服器，例如執行 8x5 (24% 用量）、10x5 (30%) 或 10x6 (36%) 的開發或 UAT 伺服器，以及執行 2% 的災難復原 (DR) 伺服器，映射到僅在使用時才計費的隨需服務。
+ **使用節省計劃採購** – 計劃使用適當的節省計劃採購生產伺服器和其他具有高用量 （大於 36%) 的伺服器，將成本降低高達 75%。選項包括 1 年和 3 年的承諾，具有不同等級的預付付款，以確保更高的折扣。
+ **移除殭屍** – 識別 CPU 使用率低於 2% 且您可以確認不再需要的伺服器，並將其從成本分析中移除。
+ **運算適當大小** – 使用 CPU 和記憶體使用率時間序列資料來評估每個伺服器所需的運算能力和記憶體。然後選取適合的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。
+ **關聯式資料庫管理系統 (RDBMS) 授權大小調整** – 在資料庫伺服器上運算大小調整後重新評估 RDBMS 授權需求、比較自攜授權 (BYOL) 和從中取得授權 AWS，並探索 Amazon Relational Database Service (Amazon RDS) 的潛力以節省成本。
+ **儲存** – 適當調整所需的總儲存磁碟區大小，並識別產品組合中每秒的輸入/輸出操作 (IOPS) 需求。決定可以移動到具有不同 SLAs 和成本的物件儲存體的程度。

## 資料需求
<a name="data-needs"></a>

[了解初始評估資料需求](understanding-initial-assessment-data-requirements.md)中的表格會顯示建置方向性商業案例的每個部分所需的資料，以及它是強制性還是選擇性的。

若要建置案例，您需要初始規劃資料的基礎設施子集加上成本資料。決定如何識別要包含的基礎設施取決於您的業務目標：
+ 如果計劃的目標是遷移和現代化特定應用程式，請考量共用的基礎設施，根據應用程式的需求來建置基礎設施產品組合。
+ 如果計劃的目標以基礎設施為中心，例如從租用即將過期的資料中心遷移，則基礎設施 TCO 比較不需要應用程式映射。

標記為選用的資料 （例如伺服器的 CPU 和記憶體尖峰使用率） 通常可以用標準基準值取代。您可以與 AWS 合作夥伴或 AWS 專業服務討論此問題。或者，您可以從產品組合中可用的資料點推斷值 （例如 Hypervisor 收集的資料）。產品組合越大，其準確性就越高。

## 建置基礎設施 TCO 比較
<a name="building-infrastructure-tco-comparisons"></a>

工具對於建構基礎設施 TCO 比較至關重要。[AWS Professional Services](https://aws.amazon.com/professional-services/) 或 [AWS 合作夥伴](https://aws.amazon.com/migration/partner-solutions/)可以提供所有類型定向案例的協助，特別是如果您計劃讓他們參與以協助更廣泛的遷移程序時。

有工具可以執行下列動作：
+ 收集庫存資料。
+ 收集使用率資料。
+ 提供準確的現狀基礎設施成本基準資料。
+ 識別和移除殭屍。
+ 進行適當大小的評估。
+ 建議購買選項。
+ 比較軟體授權選項。
+ 產生簡單的圖形現金流分析。

從 [遷移評估器](https://aws.amazon.com/migration-evaluator/) AWS 是其中一個選項。它提供所有這些功能作為**免費受管服務。您可以透過** AWS 帳戶管理員或遷移能力合作夥伴或[線上提交請求](https://pages.awscloud.com/Migration-Evaluator-request.html)來請求 AWS 遷移評估器。Migration Evaluator 專門設計為單點解決方案，可快速產生基礎設施技術 TCO 比較。

主要優點：
+ 免費
+ 無代理程式探索或庫存資料的手動組態，其中以工具為基礎的探索受到限制
+ 協助部署、組態、資料收集和建置基本案例或定向商業案例的專用支援
+ SaaS 操作的便利性，但可以完全在客戶網路中執行資料收集，以支援在載入分析引擎之前清理
+ 對 Microsoft 授權大小調整的強大支援
+ 完整的資料匯出功能 

金鑰限制：
+ 僅評估 x86 架構伺服器 (Windows 和 Linux) 
+ 設定或校正基準現狀成本資料的有限選項
+ 不支援建模操作成本最佳化
+ 不支援遷移成本建模 
+ 沒有直接支援建置 TCO 比較以外的商業案例

如果您決定使用商業探索工具進行產品組合探索和分析功能，例如應用程式堆疊和相互依存性探索，它通常也會提供基礎設施 TCO 比較。如需使用工具進行產品組合探索和評估的指引，請參閱[評估探索工具的需求](understanding-initial-assessment-data-requirements.md#discovery-tooling)。若要檢閱和比較市場領導工具的關鍵功能，請參閱[探索、規劃和建議遷移工具](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/)。

## 在營運成本最佳化中建置
<a name="building-operational-cost-optimization"></a>

IT 操作生產力改善通常是遷移的重要價值因素。根據 International Data Corporation (IDC) 白皮書[培養商業和組織轉型以透過 Amazon Web Services 產生商業價值](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)，平均而言，遷移至 後 AWS，IT 營運人員的生產力會透過遷移增加 62%。不過，調整大小並在方向性案例中包含這些優點有兩個挑戰。

首先，評估全方位的生產力提升需要廣泛的資料收集，並且更適合[詳細的商業案例](detailed-business-case.md)。此挑戰可以透過專注於幾個元素來解決，這些元素使用簡單的基準資料更容易評估和調整大小，但仍顯示顯著優勢。

其次，將生產力作為降低成本的來源，可能會在關鍵客戶利益相關者和計劃成員之間產生關注和負面。請務必清楚了解將如何實現利益，以及這對受影響人員的意義。釐清這只會增強團隊的角色，可以避免此類問題：
+ 遷移計畫包含開發內部營運人員並將其移入新角色的軌道，例如加入 DevSecOps 團隊建置基礎設施做為程式碼自動化，以及測試自動化以推動團隊成長。
+ 您可以透過調整規模和調整營運委外合約的大小來實現優勢，以便內部員工可以提高他們對更高價值活動的關注

根據您想要考慮的操作轉換來建構此商業案例元素的方法：
+ 如果您有現有的內部營運團隊，請提升團隊成員的技能，並顯示預期的生產力改善。
+ 或者，從您目前的操作解決方案遷移到 AWS Managed Services (AMS) 或從 AWS 合作夥伴遷移到替代受管服務產品。

針對第一次轉換，若要取得可納入案例之生產力改善的保守財務預估，我們建議下列事項：

1. 特別專注於伺服器管理操作生產力。它往往是操作工作的重要比例，可以更輕鬆地評估，並且稍後更容易進行驗證。

1. 根據每個全職同等 (FTE) 員工可以管理的伺服器數量基準，計算所需的人員配置。在內部部署中，該數量約為 150 個伺服器。在 上 AWS，大約有 400 個伺服器。

1. 將這些指標套用至現場部署伺服器的數量，相較於 EC2 執行個體的數量。

1. 將節省的時間與整個營運團隊的混合成本費率相乘。

然後，您可以透過驗證結果不超過下表中提供的角色的平均生產力收益 （資料來源為 IDC 白皮書[培養商業和組織轉型，以透過 Amazon Web Services 產生商業價值](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)。

 


| **Role** | **效率增益** | 
| --- |--- |
| IT 基礎設施管理 | 62% | 
| IT 支援 | 59% | 
| 應用程式管理 | 43% | 
| 資料庫管理 | 19% | 
| 應用程式開發 | 25% | 

對於第二個轉換，您可以直接比較範圍內產品組合目前的總操作和支援成本，以及考慮的受管服務成本，以增加營運成本節省。

若要取得受管服務的成本，請將您提議的物料 AWS 清單、服務層級選擇 (Plus 或 Premium) 和 AMS 套件 (AMS Accelerate 或 AMS Advanced) 提供給 AWS 您的帳戶管理員或任何[AWS Managed Services 合作夥伴](https://aws.amazon.com/managed-services/partners/)。這將為您提供 受管服務的總成本：AWS 服務 轉換解決方案的元件。同樣地，您可以從根據自己的參數提供自己的受管服務套件的 AWS 合作夥伴取得定價。

## 擴展到全方位商業案例
<a name="full-directional-business-case"></a>

一般而言，若要組合全方位商業案例，請建立 TCO 比較，包含或不包含 IT 生產力元素，並預估所有遷移和現代化成本。然後建立現金流程，涵蓋一組migrate-and-modernize，以及不t-migrate-and-modernize案例。

最基本的案例是準備單對案例，其中 t-migrate-and-modernize 案例是您目前的情況，而 migrate-and-modernize 案例具有下列特性：
+ 交易量、運算或聯網容量沒有增長或縮減
+ 儲存需求的穩定低容量成長
+ 符合現有系統功能Quality-of-service（例如可用性、耐用性、輸送量和效能）

對於除了非常小的所有產品組合，這符合建置方向性案例的目標。它會快速示範足夠的值，以取得繼續前進的命令。

對於較小的產品組合，新增一組migrate-and-modernize和不t-migrate-and-modernize案例可能很有價值，這些案例示範雲端遷移增加價值的其他方面，例如：
+ 跨工作負載的中等和高容量成長需求混合，這些工作負載預期會成長
+ 包含增強的彈性，例如高可用性、DR 和容錯能力
+ 透過邊緣運算、內容交付網路 (CDN)、多區域資料庫複寫來改善全域效能。
+ 您為計劃設定業務優先順序的任何其他特定改善服務品質

對於這些案例，請確保準確估計升級目前非雲端基礎設施架構以符合新規格的成本和現金流影響。取得此預估值最直接的方式可能是向系統整合商請求引號，特別是如果他們也是具有遷移能力的 AWS 諮詢合作夥伴，他們可以同時支援migrate-and-modernize和不t-migrate-and-modernize案例。

針對每組案例，組合包含下列項目的案例：
+ t-migrate-and-modernize 案例的成本。在最基本的情況下，這包括：
  + 目前基礎設施組態之業務案例期間的總擁有成本
  + 運算、儲存和網路流量使用量的定期增加 
+ migrate-and-modernize的成本； 案例，包括：
  + 設定計畫，其中包括詳細探索、遷移規劃、詳細業務案例開發、建立核心團隊並提升技能、建立尚未就緒的登陸區域，以及建立遷移工作負載的安全管理和操作整合
  + 工作負載遷移和現代化成本 
  + 遷移基礎設施成本，包括網路連線、 [AWS Snowball Edge](https://aws.amazon.com/snowball/) 和 等資料遷移服務[AWS DataSync](https://aws.amazon.com/datasync/)，以及遷移程序本身所需的架構 AWS 公用程式成本 （例如，用於測試）
  + 隨著波浪上線，遷移過程中 AWS 的公用事業成本逐步增加，以及現有基礎設施成本在以 AWS 服務取代和停用時逐漸降低
+ 任何分層資產的除役成本和沖銷

## 估算遷移和現代化程式設定
<a name="estimating-migration-and-modernization-program-setup"></a>

若要設定成功計劃，您可能需要執行一系列的基礎活動，以建立基準功能，如果之前沒有這麼做，則需要詳細計劃。這些基礎活動包括下列項目：

1. 執行詳細的產品組合探索、遷移規劃和詳細的商業案例開發，如[產品組合分析和遷移規劃](portfolio-analysis-migration-planning.md)一節所述，以及記錄使用的任何探索工具的成本。

1. 建立雲端業務和技術核心團隊，並透過培訓和招聘開發內部技能。識別需要訓練的 IT 組織成員，並為每個人分配訓練預算。

1. 建立[登陸區域](https://aws.amazon.com/solutions/implementations/aws-landing-zone/)並加以設定，以支援您需要的成本、營運和安全控管功能。

AWS 諮詢合作夥伴可協助提供項目 1 和 3 的預估值。

*估算遷移和現代化成本*

為了達成有方向性商業案例的目標，並展現*足以*進入下一個階段的商業潛力，請盡可能維持基本的遷移和現代化成本估算。

為此，我們建議您專注於以下遷移策略中的應用程式，以準備方向性商業案例：
+ 淘汰
+ 保留
+ 重新定位
+ 重新託管
+ 平台重建
+ 重新購買

一般而言，大約 70% 的工作負載可以重新託管、重新定位或重新格式化，另外 5% 可以淘汰。透過遷移策略評估應用程式通常會解決降低成本案例的核心。

估算重構或重新架構的成本****可能很複雜。在準備有方向性的商業案例所指定的時間範圍內嘗試這麼做並不實際。如先前[在決定遷移的 R 類型](prioritization-and-migration-strategy.md#migration-r-type)中所討論，請考慮在遷移和現代化的第一階段使用重新託管、重新定位或轉換策略。這些 R 策略可能會加速初始回報、降低實作風險，並在短期內改善業務案例。與您的應用程式團隊相比，將環境中執行的應用程式現代化也相當容易 AWS 。準備[詳細的商業案例](detailed-business-case.md)時，最好新增重構 （重新架構） 特定應用程式的估算。

*依策略估算遷移的工作量*

每次遷移都不同。在遞交任何預算或計劃之前，將由負責專案的團隊提供遷移活動的種子工作負載預估，無論是您的內部應用程式團隊、 AWS 專業人員服務或 AWS 合作夥伴組織。

為了協助建置方向性案例，下表提供不同處理方式的指示性工作量範圍。這些範圍假設medium-to-large產品組合正在遷移，且遷移團隊經過訓練且經驗豐富。對於小型產品組合，即使是有方向性的案例，最好讓負責遷移的團隊準備預估值。


| 遷移策略 | 估算程序 | 元素 | 人員時數 | 人員時數 | 
| --- |--- |--- |--- |--- |
| Retain | Do nothing, with no cost, no benefits, and no reduction in technology debt. | – | – | – | 
| Retire | Estimate decommissioning the hardware equipment used, if any. | – | – | – | 
| Relocate | Estimate copying the workload within VMware using VMware tools. This includes copying the data, smoke testing to verify, and any hardware decommissioning. The effort to relocate VMs is typically less than for low-complexity rehost patterns. | – | – | – | 
| Rehost | Estimate copying the workload and data with an image copy, smoke testing, high availability (HA) and disaster recovery (DR) testing where appropriate for production servers, and any hardware decommissioning. The best practice is to use tools such as [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/). Divide workloads into low, medium, and high complexity, based on factors such as whether a database or other infrastructure software is running, database complexity, whether clustered, integration complexity, and data volumes. | Effort per app per server | Migration | HA/DR test | 
| Low | 10–14 | 3–5 | 
| Medium | 16–24 | 4–6 | 
| High | 26–38 | 8–12 | 
| Replatform | For replatform migrations that include upgrades to operating system or RDBMS version, take the estimate for a rehost, and add time to run a rebuild and smoke test on the new platform.If the replatform includes changing the technology of the platform, estimate additional time for the use of the conversion tools, such as [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/) and [AWS Database Migration Service](https://aws.amazon.com/dms/), and a more complete application test. An example of changing the technology is migrating away from a proprietary commercial database to an open source replacement. | Effort per app per server | Version up | Technology change | 
| Low | Add 1–3 | Add 10–15 | 
| Medium | Add 2–5 | Add 20–30 | 
| High | Add 4–8 | Add 40–60 | 
| Repurchase | Estimate data extraction, transformation, and uploading into the newly purchased SaaS service replacement, and any hardware decommissioning. | – | – | – | 

*估算遷移基礎設施成本*

包含您將在遷移過程中使用的基礎設施預估值。一般而言，這些預估值包含：
+ 從目前環境到 的工作負載和資料遷移的連線和資料交換服務預算 AWS
+ 在遷移、測試和切換程序期間託管遷移工作負載所需的預算 AWS 服務 （特別是運算和儲存）
+ 當每個遷移波動完成時， AWS 公用程式成本的增加
+ 不再執行遷移工作負載之現有基礎設施的除役成本

對於資料交換，請檢查您的總資料磁碟區，並評估使用聯網的可行性。如果您已在遷移後事先在 WAN 上佈建[AWS Direct Connect](https://aws.amazon.com/directconnect/)連結[Site-to-Site VPN](https://aws.amazon.com/vpn/)或從 佈建 AWS 至某個點以供操作使用，則可以使用該資源達到其服務配額。

如果您的網路容量不足，透過虛擬私有網路 (VPN) 短期增加網際網路頻寬通常是高成本效益的解決方案。如果沒有，例如 [AWS Snowball Edge](https://aws.amazon.com/snowball/)和 等 AWS 媒體交換裝置在大多數情況下[AWS Snowball Edge](https://aws.amazon.com/snowcone/)都會提供解決方案 AWS 區域。此外，對於非常大量的資料遷移，請考慮包含 的預算[AWS DataSync](https://aws.amazon.com/datasync/)，這可提高可靠性並加速傳輸，無論使用的媒體為何。

對於商業案例的現金流程分析元素而言，建立 AWS 服務漸進和現有基礎設施漸進漸進的模型非常重要。在此階段，您不太可能有波動計畫來確切判斷何時產生成本。我們建議下列作法：
+ 相較於遷移，以 AWS 固定速率提高 的成本。
+ 縮減您計劃在相同持續時間內以固定速率解除委任的現有基礎設施的成本。

在現有基礎設施下降前 1-2 個月開始 AWS 成本上升。這提供 1 個月的 AWS 公用程式用量，以針對每一波進行遷移。其中包括測試時間，以及完成停止取代基礎設施產生成本所需的除役工作所需的額外時間。

*預估除役成本*

停用無法重新部署的設備，並以合法且對環境友善的方式處置，可能會產生一些小成本。不過，對於有方向性的商業案例，通常唯一的可能重大總和是沖銷所取代資產任何剩餘帳面價值的成本。

對於定向商業案例，我們建議您執行下列動作：
+ 檢閱您的資產清單。
+ 識別要停用的那些。
+ 若要減少沖銷，請檢查切換裝置的機會，以便清單中較新的裝置可用來取代較舊、已完全棄用的資產。
+ 評估屆時將停用的資產的未來帳面價值。
+ 將此納入為解除委任的遷移成本。

*組合和調整全方向商業案例*

在您準備每組案例的完整一組成本之後，請建構每個案例的折扣現金流陳述式，並繪製它們的圖形。我們建議您在硬體重新整理週期的同一期間建置有方向性的商業案例。伺服器、儲存和網路裝置通常需要 5 年的時間。當您使用與硬體重新整理週期相同的期間時，每個案例的現狀成本中只會包含一次重新整理的成本。

然後計算取得核准以進入計劃下一個階段所需的關鍵財務指標。我們通常包含下列項目：
+ 用來評估成本降低和生產力提高的絕對值的淨現值 (NPV)
+ 驗證傳回是否足夠快的傳回期間，以月為單位
+ 最終執行速率比較，以驗證程序是否在期間內耗用足夠的成本
+ 投資報酬率 (ROI) 和修改後投資報酬率 (MIRR)，以評估相較於組織可能優先考慮的其他資本需求，計畫相對的財務績效

使用案例的第一次反覆運算來判斷預期的財務效能是否意味著應進行精簡，如下列範例所示：
+ 如果傳回太慢，請考慮加速和降低遷移成本的選項，如下所示：
  + 使用 AWS 合作夥伴或 AWS 專業服務來擴展可用資源，並以更基本的模式進一步平行化遷移工作負載。
  + 對於在 VMware 中執行的工作負載，請至少在初始階段比較重新放置策略與重新託管或轉換策略。使用重新定位策略可以降低遷移成本並提高遷移速度。
  + 在技術上可行的情況下，將需要更複雜轉換或重構 （重新架構） 策略的工作負載推送到初始業務案例範圍以外的未來階段。
+ 如果 ROI 和 MIRR 太低，請考慮下列事項：
  + 您考慮的情境是否過於保守？ 您是否有反映最可能容量成長和彈性需求的案例？ 您是否有比較成本的案例，包括目標內服務品質的增加？
  + 您可以縮小在第一階段要遷移的應用程式產品組合範圍，以專注於將產生更強大回報的工作負載，例如目前使用率較低或需要昂貴的災難復原 (DR) 的工作負載嗎？
  + 可以縮小應用程式產品組合的範圍，以最初排除在商業上達成較少的特定工作負載嗎？ 例如，您可以延遲第三方軟體授權因為在公有雲端基礎設施中部署的不同條款而變得更昂貴的工作負載嗎？
+ 如果最終執行速率比較不符合預期目標，請探索以下內容：
  + 首先，確認其他指標符合預期。有方向性的商業案例主要是顯示有足夠的財務機會來證明開始下一階段的遷移準備。
  + 識別在遷移初始階段 AWS 之後，繼續改善 成本效能的機會清單。

在準備詳細的商業案例時，包括機會清單的評估。此外，請在持續維護案例和遷移完成後month-to-month成本最佳化程序中納入機會評估。