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

# 建立定向商業案例
<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/)可以提供所有類型定向案例的協助，特別是如果您計劃讓他們參與以協助更廣泛的遷移程序時。 

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

從 AWS [遷移評估器](https://aws.amazon.com/migration-evaluator/)是其中一個選項。它提供所有這些功能作為**免費受管服務。您可以透過** 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 的預估值。 

### 估算遷移和現代化成本
<a name="estimating-migration-and-modernization-costs.30d972c9-a147-5e96-9cbc-98457248608c"></a>

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

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

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

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

### 依策略估算遷移的工作量
<a name="estimating-effort-for-migration-by-strategy.68a74030-6989-5440-89e8-24737301321d"></a>

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

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


| 
| 
| 遷移策略 | 估算程序 | 元素 | 人員時數 | 人員時數 | 
| --- |--- |--- |--- |--- |
| 保留 | 不做任何事，沒有成本、沒有好處，也不會減少技術債務。 | – | – | – | 
| 淘汰 | 預估停止使用的硬體設備，如果有的話。 | – | – | – | 
| 重新定位 | 使用 VMware 工具估計在 VMware 內複製工作負載。這包括複製資料、要驗證的煙霧測試，以及任何硬體停用。重新放置 VMs 的努力通常小於低複雜度重新託管模式。 | – | – | – | 
| 重新託管 | 預估在適合生產伺服器的情況下，使用映像複製、煙霧測試、高可用性 (HA) 和災難復原 (DR) 測試，以及任何硬體停用來複製工作負載和資料。最佳實務是使用 等工具[AWS Transform MGN](https://aws.amazon.com/application-migration-service/)。根據資料庫或其他基礎設施軟體是否正在執行、資料庫複雜性、叢集、整合複雜性和資料磁碟區等因素，將工作負載劃分為低、中和高複雜度。 | 每個伺服器每個應用程式的工作量 | 移轉 | HA/DR 測試 | 
| 低 | 10–14 | 3–5 | 
| 中 | 16–24 | 4–6 | 
| 高 | 26–38 | 8–12 | 
| 平台重建 | 對於包含升級到作業系統或 RDBMS 版本的轉換遷移，請估計重新託管，並增加在新平台上執行重建和煙霧測試的時間。如果轉換包含變更平台的技術，請預估使用轉換工具的額外時間，例如 [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/)和 [AWS Database Migration Service](https://aws.amazon.com/dms/)，以及更完整的應用程式測試。變更技術的範例是從專屬商業資料庫遷移到開放原始碼替換。 | 每個伺服器每個應用程式的工作量 | 版本提升 | 技術變更 | 
| 低 | 新增 1–3 | 新增 10–15 | 
| 中 | 新增 2–5 | 新增 20–30 | 
| 高 | 新增 4–8 | 新增 40–60 | 
| 重新購買 | 預估資料擷取、轉換和上傳到新購買的 SaaS 服務替換，以及任何硬體停用。 | – | – | – | 

### 估算遷移基礎設施成本
<a name="estimating-migration-infrastructure-costs.fef93719-1e74-5598-af75-7c653f62b1f2"></a>

包含您將在遷移過程中使用的基礎設施預估值。一般而言，這些預估值包含：
+ 從目前環境到 的工作負載和資料遷移的連線和資料交換服務的預算 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 公用程式用量，以針對每一波進行遷移。其中包括測試時間，以及完成停止取代基礎設施產生成本所需的除役工作所需的額外時間。

### 估算除役成本
<a name="estimating-decommissioning-costs.ff030f84-cce0-50fe-9b3c-499176120c37"></a>

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

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

### 組合和調整全方向商業案例
<a name="assembling-and-adjusting-the-full-directional-business-case.6b772d69-7f05-5a36-a27f-44e2c42808ed"></a>

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

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

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

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