遷移評估、7Rs 策略與 Wave 規劃

AWS Solutions Architect Professional（SAP-C02）的遷移評估，是一門將雜亂無章的地端環境轉化為有優先順序、有資金支撐、規劃好 wave 的遷移方案的學科。在 Pro 深度，遷移評估 7Rs 絕非術語背誦——它是一條從 AWS Cloud Adoption Framework (CAF) 整備審查開始，取得 AWS Migration Acceleration Program (MAP) funding 資格，以 AWS Application Discovery Service 探索所有工作負載，用 AWS Migration Evaluator 建立 TCO，依 7Rs 決策矩陣 分類每個應用程式，最後透過 AWS Migration Hub 以相依性感知的 wave 規劃執行的完整流程。

SAP-C02 Domain 4 任務陳述 4.1 測試你能否在真實企業情境下端對端地執行遷移評估。典型考題情境如下：「某公司旗下 12 個資料中心共有 500 個應用程式，必須在 18 個月內完成資料中心退場，技術棧混合（Windows、Linux、AS/400、Oracle、VMware、可 SaaS 替換的 CRM）。CFO 要求在核准預算前提供商業論證。」 若你能看到這個情境，立刻對應出 CAF → MAP Mobilize → Migration Evaluator → MPA → 7Rs 分類 → wave 規劃的流程，遷移評估題目就能輕鬆過關。

Pro 規模的遷移評估問題

遷移評估在本質上與 Associate 等級的「替這一個 app 選對的 R」問題截然不同。在 Pro 規模，你評估的不是單一應用程式——你評估的是整個應用程式組合（portfolio），而 portfolio 級的遷移評估需要完全不同的資料結構、資金工具與治理模型。

500 個應用程式的遷移評估會暴露三個在小規模時不存在的問題：

1. 異質性（Heterogeneity） — 500 個 app 橫跨 COTS 套裝、自研 Java、.NET、AS/400、SaaS 及影子 IT。沒有任何一個 R 能一體適用；你需要一套決策矩陣，有系統地將工作負載特性對應到 R 策略。
2. 相依性（Interdependencies） — 應用程式共用資料庫、訊息佇列與驗證服務。天真的「每波一個 app」計畫一定失敗，因為 Wave 3 還在讀 Wave 7 的資料庫。你需要相依性感知的 wave 排序。
3. 資本限制（Capital constraints） — 500 個 app × 18 個月，代表你無法自行負擔評估費用。你需要 AWS MAP funding，而 MAP funding 要求在第一波開始前先提交由 CFO 簽字的 Migration Evaluator TCO 商業論證。

以上三個問題，正是 SAP-C02 遷移評估考題總是提到 portfolio 規模（100+、500+、1000+）、截止日（12-24 個月）及混合技術棧的原因。考試在探測你是否知道**方案層級（program-level）**的答案，而非每個 app 的 R。

白話文解釋 — 遷移評估如同城市遷村工程

把遷移評估想像成：不是搬一戶家，而是整個社區 500 戶人家要在 18 個月內搬到新城市。你不能靠一家搬家公司、一張清單、或一條「這件家具要不要帶」的規則就搞定。你需要一整套流程來管理整個搬遷工程。

類比一 — 遷移評估如同捷運系統搬站工程

把 500-app migration 當成台灣某城市的捷運系統整個搬遷（新路線啟用，舊站全部遷移至新站點）：

• CAF 6 perspectives：市政府六個局處（財政局、人事局、法規局、工程局、安全局、交通局）要先確認整個城市真的準備好搬遷。沒有市政府背書，搬遷工程一定亂成一團。
• MAP 3 phases (Assess / Mobilize / Migrate)：分三個階段向中央政府申請搬遷補助——先評估是否值得搬、再動員籌備、最後執行搬遷。沒有補助金根本搬不完。
• Application Discovery Service：工程人員挨站挨站做現地勘查——每站有多少設備、哪些設施、與哪一站有路線相依關係。沒有勘查一定有遺漏。
• Migration Evaluator：工程會計師計算搬遷總成本 vs 維持舊站運作 3 年的成本——TCO model。沒有這本帳 CFO 不會點頭。
• Migration Portfolio Assessment (MPA)：將每個站分類——廢棄小站（retire）、暫不搬的釘子站（retain）、整站打包直接平移（rehost）、順便更換月台設備再搬（replatform）、乾脆改成 UBike 租賃站（repurchase）、整條路線重新規劃（refactor）。
• Wave planning：不能一天 500 站同時搬——會癱瘓新路線的基礎建設。分成波次，每波 30-50 站，先搬獨立終點站、再搬共用轉乘站群組、最後搬最複雜的樞紐站。

類比二 — 7Rs 決策矩陣如同工廠設備盤點分類

把 7Rs decision matrix 當成工廠大搬遷前的設備盤點桌：廠房裡每一台機器都要先回答三個問題——「還在生產嗎？能搬嗎？值得重建嗎？」——然後才決定用哪一套處理方案。

• Retire：報廢閒置的老車床——直接拆除報廢。SAP-C02 情境常說 "no login in 24 months, duplicate capability"。
• Retain：租賃合約尚未到期的設備——暫時留置。常見提示："3-year vendor contract"、"regulatory requires on-prem"、"latency < 5ms to factory floor"。
• Relocate：整條 VMware 虛擬產線原封不動拖到新廠（VMware Cloud on AWS）——無法改造但要極速搬走。
• Rehost：機器插頭拔掉直接裝上貨車（AWS MGN lift-and-shift）——最快，但沒享受到雲端優化。
• Replatform：搬過去順便把舊氣壓系統換成伺服電動系統（self-managed MySQL → Amazon RDS）——中度效益、中度工期。
• Repurchase：整套機具不要了，直接向外部廠商訂閱生產服務（legacy CRM → Salesforce）——用 SaaS 取代自建。
• Refactor：整個廠房打掉重建，引入自動化產線與 IoT 感測（monolith → Lambda + DynamoDB + Step Functions）——最高效益、最高投入。

類比三 — Wave Planning 如同工地施工排程

Migration 的 wave planning 就像大型工地的施工順序。你不能同時挖地基、蓋屋頂、裝玻璃——必須依相依性排序。Wave 1 是獨立小棟（standalone apps），Wave 2 是共用地下車庫的連棟（shared database groups，稱為 affinity groups），Wave 3 是複雜的地標建築（complex interdependencies with legacy mainframe）。Dependency graph 就是工地的結構配筋圖——告訴你哪些梁柱先施作、哪些後施作。AWS Migration Hub 就是工地的指揮中心（command centre）——每個 wave 的進度、每個 app 的狀態、每個相依風險都集中在此查看。

AWS Cloud Adoption Framework (CAF) — Pro 深度六大視角

AWS CAF 是遷移評估的組織整備層。在 SAP-C02 深度，CAF 不是「列出六個視角的名稱」——而是「給定企業痛點，哪個 CAF 視角負責補救，以及涉及哪些能力？」

Business 視角 — 策略與投資

負責人：CEO、CFO、COO、CIO、業務線主管。

Pro 深度測試的能力：策略管理、portfolio 管理、創新管理、產品管理、策略夥伴關係、資料貨幣化、業務洞察。

SAP-C02 考題提示："CEO wants to tie the migration to new revenue streams within 24 months" → Business 視角。情境聚焦於策略到成果的對齊，屬於 Business 而非 Governance。

People 視角 — 文化與雲端素養

負責人：CHRO、CIO、Cloud Center of Excellence (CCoE) 負責人。

Pro 深度的能力：文化演進、變革領導力、cloud fluency、人力轉型、變革管理、組織設計、人才管理。

SAP-C02 考題提示："500 legacy sysadmins need to become cloud engineers in 12 months; retention is a risk" → People 視角。Cloud fluency 培訓、再培訓路徑及 CCoE 組建均屬 People 的職責。

Governance 視角 — 方案與風險管理

負責人：CIO、CTO、CFO、Chief Risk Officer (CRO)、Chief Data Officer (CDO)。

能力：方案與專案管理、效益管理、風險管理、cloud financial management (CFM)、應用程式 portfolio 管理（APM）、資料治理。

SAP-C02 考題提示："Migration must stay within $12M budget across 18 months with monthly showback to business units" → Governance 視角。Cloud financial management 與效益實現屬於此視角。

Platform 視角 — Landing Zone 與工程

負責人：CTO、雲端架構師、工程主管。

能力：平台架構（landing zone）、資料架構、平台工程、資料工程、佈建與協調（Control Tower、Account Factory）、現代化應用程式開發、CI/CD。

SAP-C02 考題提示："Before the first migration wave, we need Control Tower landing zone, shared services account, and CI/CD pipelines ready" → Platform 視角。

Security 視角 — 機密性、完整性、可用性、隱私與韌性

負責人：CISO、Chief Compliance Officer (CCO)、內部稽核。

能力：安全治理、安全保證、身份與存取管理、威脅偵測、漏洞管理、基礎設施保護、資料保護、應用程式安全、事件回應。

SAP-C02 考題提示："Migration must satisfy HIPAA, PCI-DSS, and SOC 2 across all landing zone accounts" → Security 視角。

Operations 視角 — 運行與維運

負責人：CIO、COO、SRE / 平台團隊。

能力：可觀測性、事件管理（AIOps）、事故與問題管理、變更與發佈管理、效能與容量管理、組態管理、patch management、可用性與連續性管理、應用程式管理。

SAP-C02 考題提示："Post-migration, 24/7 on-call must cover 500 workloads with 15-minute MTTA" → Operations 視角。

AWS Migration Acceleration Program (MAP) — 三個階段與 Funding 資格

MAP 是 AWS 的旗艦遷移方案與資金工具。在 Pro 深度，你必須了解三個階段、funding 資格條件，以及 AWS 在每個階段提供的工具。

第一階段 — Assess

目標：判斷遷移是否值得，並建立商業論證。

活動：CAF 整備評估、Migration Readiness Assessment (MRA) 工作坊、Migration Evaluator（前身為 TSO Logic）TCO 分析、方向性商業論證、主管層級共識建立。

產出物：

• 橫跨 CAF 六個視角的 MRA 報告
• 方向性 TCO（通常為 3 年或 5 年預測）
• 初步應用程式清查（高階層）
• 主管簽核進入 Mobilize 階段

資金：有限——通常為評估本身的 AWS Professional Services 或 AWS Partner Network (APN) Migration Competency 夥伴點數。

第二階段 — Mobilize

目標：彌補 Assess 階段找出的組織缺口，為大規模遷移做好準備。

活動：

• Landing zone 建置（AWS Control Tower、Account Factory、共用服務帳號）
• 使用 Application Discovery Service（agentless + agent-based）進行詳細應用程式探索
• 執行 Migration Portfolio Assessment (MPA) 為每個應用程式評分
• Migration Experience Building — 通常遷移 5-15 個試行應用程式，驗證遷移工廠運作
• Cloud Center of Excellence (CCoE) 組建與人員配置
• 定義作業模型（遷移後誰負責維運什麼）

產出物：

• 正式上線的 landing zone
• 附 7Rs 分配的完整應用程式 portfolio 清查
• 含 dependency graph 的 wave 計畫
• 切換（cutover）runbook 範本
• 簽核完成的詳細商業論證

資金：MAP Mobilize funding — AWS 提供現金點數（通常為預估 12 個月 AWS 花費的 15-25%），用於抵扣合格費用。需要承諾書與主管級贊助。

第三階段 — Migrate and Modernize

目標：執行 wave 計畫並停用源頭資料中心。

活動：

• 逐 wave 執行：以 AWS Application Migration Service (MGN) 進行 Rehost、AWS DMS 遷移資料庫、AWS DataSync 遷移檔案資料、AWS Snow Family 進行大量離線傳輸
• 透過 Migration Hub 追蹤每個工作負載狀態
• 逐工作負載進行遷移後 Well-Architected Framework 審查
• 現代化疊加層（在初始 Rehost 後進行 Refactor wave）
• 資料中心停用

產出物：

• 範圍內所有工作負載均已遷移或退役
• 源頭資料中心停用完成
• 對比商業論證的實際節省
• 後續 wave 的現代化積壓清單

資金：MAP Migrate funding — 較大的點數池（通常為遷移視窗期間預估 AWS 花費的 25-50%），以 wave 里程碑與夥伴參與作為開放條件。

MAP Funding 資格條件（Pro 深度）

SAP-C02 遷移評估考題有時會探查誰有資格申請 MAP funding。答案並非每個客戶都有——MAP 是有條件的商業方案：

• 最低遷移規模：通常 1000 台以上伺服器或同等工作負載量，但較小規模方案可透過 MAP Small Segment (MAP-SS) 或 MAP for Windows 取得資格。
• 承諾的 AWS 花費：遷移後每年 AWS 消耗的預測值（完整 MAP 通常須達 $1M+）。
• 主管贊助：C 級主管確認此次遷移具策略意義。
• 夥伴參與：大多數 MAP 方案透過 AWS Migration Competency 夥伴執行，由夥伴提供 Professional Services 並共同投入。
• 評估完成：不能跳過直接申請 Migrate 資金；必須先完成 Mobilize。

考題提示：若情境說「公司希望 AWS 資助遷移，但只有 40 台伺服器且沒有現有 AWS 花費」——MAP 不是正確答案；應改用 AWS Migration Hub Strategy Recommendations 搭配自費 Professional Services，或使用 APN 夥伴的 SMB 遷移方案。

AWS Application Discovery Service — Agentless Connector vs Agent

AWS Application Discovery Service (ADS) 是將地端工作負載資料填充到 Migration Hub 的技術探索引擎。在 SAP-C02 深度，你必須區分兩種探索模式、各自的前提條件，以及各自收集的資料。

Agentless Discovery Connector

• 形式：部署到 VMware vCenter（ESXi）的 OVA。
• 收集：VM 層級清查（VM 名稱、CPU、記憶體、磁碟、NIC）、VM 效能指標（CPU 使用率、記憶體使用率、網路吞吐量）、來自 vCenter 中繼資料的基本相依性。
• 不收集：程序層級清查、網路連線詳情、應用程式層級相依性。
• 使用時機：源頭環境僅有 VMware、不能安裝 agent（合規、變更窗口、作業風險）、需要快速覆蓋。
• 可用資料延遲：通常需要 2 週觀察，才能累積有意義的使用率樣式。

Application Discovery Agent

• 形式：安裝在每台 Windows 或 Linux 伺服器上的輕量 agent（實體機、VMware、Hyper-V、KVM 或雲端）。
• 收集：Agentless 的所有資料，加上執行中程序、TCP/UDP 連線（來源 IP、目的 IP、埠、程序名稱）、已安裝應用程式，以及更高精度的效能資料。
• 使用時機：需要程序層級相依性對應、非 VMware hypervisor（Hyper-V、KVM）、實體伺服器，或準確的應用程式間流量地圖。
• 取捨：需要跨所有伺服器部署 agent——作業負擔較重，但能產出 wave 規劃所需的高精度相依性資料。

AWS Migration Hub Strategy Recommendations（現代化評估）

在 ADS 之上，Migration Hub Strategy Recommendations 分析探索資料並為每個應用程式產生 7Rs 建議與現代化路徑（例如：「此台 WebLogic 上的 Java EE 單體是將 Refactor 為 ECS + Aurora PostgreSQL + Lambda 容器架構的候選」）。它消耗 ADS 資料加上可選的反模式分析二進位檔。

AWS Migration Evaluator — TCO 引擎

AWS Migration Evaluator（前身為 TSO Logic）是商業論證引擎。它吸收探索資料，結合 AWS 定價、Reserved Instance / Savings Plans 建模，以及 Graviton / 受管服務假設，產出 CFO 能夠簽核的可信 TCO。

Migration Evaluator 產出什麼

• 方向性 TCO（Assess 階段）：以 Rehost 為主的組合假設下，3 年或 5 年預測，準確度區間 ±20%。
• 詳細 TCO（Mobilize 階段）：每個應用程式的目標架構、右尺寸執行個體、Reserved Instance / Savings Plans 覆蓋假設、儲存類別假設、資料傳輸建模。
• 對比視圖：地端穩態成本（含硬體更新週期、資料中心租賃、電力、冷卻、人員）vs AWS 目標態成本。
• 敏感度分析：±10% 使用率、±20% Savings Plan 覆蓋率、Graviton 採用率的影響。

Migration Evaluator vs TCO Calculator vs Pricing Calculator

三個工具、三種用途——SAP-C02 有時會區分這三者：

• AWS Pricing Calculator：針對特定架構的假設估算。輸入由你指定；無探索資料，無地端對比。
• TCO Calculator（舊版 Simple Monthly Calculator 的繼承者）：高層次 CapEx vs OpEx 比較；不適用於 SAP 規模的 portfolio 遷移。
• Migration Evaluator：由實際探索資料與使用率驅動的 Portfolio 規模 TCO。「CFO 要求 500 個應用程式的可信商業論證」的正確答案。

7Rs 決策矩陣 — Pro 深度

在 SAP-C02 深度，每個 R 都有精確的觸發條件——一組使該 R 成為正確答案的工作負載特性。以下是可直接用於考試的決策矩陣。

Retire — 停用（不遷移）

觸發條件：應用程式 12 個月以上未被存取；功能被其他系統重複覆蓋；技術已終止支援且無業務負責人；所含資料為冗餘資料或可封存至 S3 Glacier。

SAP-C02 情境提示："no logins in 18 months"、"duplicate wiki systems"、"superseded by the SaaS rollout last year"、"the business unit it served was divested"。

評估行動：與業務負責人確認後，將資料封存至 S3 Glacier Deep Archive（若需偶爾讀取則用 S3 Glacier Instant Retrieval），關閉系統，從遷移範圍移除。探索期間健全的企業 Retire 比例為 portfolio 的 10-20%。

Retain — 留在地端（延後）

觸發條件：法規或資料主權障礙（資料必須實體留在地端）；大型主機工作負載無具成本效益的雲端替代方案；對實體硬體的延遲限制（廠房地板、醫療裝置、HFT）；有效的多年廠商合約且提前終止需付違約金。

SAP-C02 情境提示："contract expires in 2027"、"regulator requires data on-premises"、"<1ms latency to PLC floor"、"mainframe COBOL with no vendor cloud offering"。

評估行動：記錄 Retain 原因並設定複查日期，與障礙到期日連動。Retain 不是「放棄了」——而是一個有意為之、有時限的延後。

Relocate — Hypervisor 層級搬移（VMware Cloud on AWS）

觸發條件：環境以 VMware 為主，團隊熟悉 vSphere 而非 EC2，資料中心退場截止日太緊而無法在 Rehost 層級重新平台化，可接受繼續在 AWS 上支付 VMware 授權費用。

SAP-C02 情境提示："600 VMware VMs, team not retrained for EC2, 6 months to data-center exit"、"preserve IP addresses across cutover"、"no agents allowed"。

評估行動：採購 VMware Cloud on AWS (VMC) SDDC，使用 VMware HCX 進行遷移，在 hypervisor 層級切換。取捨：VMC 授權成本 vs 速度。

Rehost — Lift-and-Shift 至 EC2（無程式碼變更）

觸發條件：資料中心退場截止日凌駕一切其他考量；應用程式行為尚稱正常（有狀態但不奇特）；資料庫受 RDS 支援或可在 EC2 上執行；遷移視窗期間團隊無餘力進行 Replatform。

SAP-C02 情境提示："exit data center in 12 months"、"no code changes, move as-is"、"budget for optimization later"。

評估行動：使用 AWS Application Migration Service (MGN) 進行 agent-based 區塊層級複製，每個應用程式的切換視窗為數小時，遷移後再優化。大型遷移的典型 Rehost 比例：portfolio 的 50-70%。

Replatform — Lift-Tinker-and-Shift

觸發條件：工作負載可從受管服務替換中獲得顯著效益，無需完全重寫；自管資料庫造成作業負擔；自管中介軟體有已知的擴展痛點；遷移視窗內可接受適度的程式碼/設定變更。

SAP-C02 情境提示："self-managed MySQL → Amazon RDS"、"Apache + Tomcat on EC2 → Elastic Beanstalk"、"self-managed Redis → ElastiCache"、"connection string change acceptable"。

評估行動：應用程式層搭配 MGN，資料庫搭配 AWS DMS + SCT，或採用 Elastic Beanstalk / ECS 的 web 層。大型遷移的典型 Replatform 比例：portfolio 的 15-25%。

Repurchase — Drop-and-Shop（SaaS 替換）

觸發條件：工作負載是通用商業功能（CRM、ERP、HRIS、電子郵件、協作、ITSM）；成熟的 SaaS 市場存在；SaaS 訂閱的 TCO 低於 Rehost + 維運；業務端願意接受流程調整。

SAP-C02 情境提示："legacy Siebel CRM"、"on-prem Exchange"、"custom HRIS"、"ServiceNow replacement of legacy ticketing"。

評估行動：確定 SaaS 目標（Salesforce、Workday、Microsoft 365、ServiceNow），規劃資料遷移與使用者佈建（SCIM 至 IAM Identity Center），停用源頭系統。典型比例：portfolio 的 5-10%。

Refactor / Re-architect — 雲端原生重新設計

觸發條件：現有架構是業務成長的擴展瓶頸；目前成本結構在預估規模下不可持續；功能交付速度受單體架構限制；戰略型應用程式，雲端原生效益（serverless 擴展、事件驅動成本）值得重建投入。

SAP-C02 情境提示："monolith cannot scale past 10K RPS"、"release frequency stuck at monthly"、"strategic digital product"、"cost per transaction must drop 60%"。

評估行動：Refactor 幾乎不會是 500 個 app 的 18 個月遷移視窗內的遷移階段活動——而是遷移後現代化 wave。典型計畫：在 Wave 2 先 Rehost 單體，以 API Gateway + Lambda + DynamoDB 建立 Strangler Fig，遷移後 12-18 個月逐能力替換。遷移視窗內的典型比例：portfolio 的 5%；遷移後現代化積壓中則高得多。

7Rs 決策矩陣表

Migration Portfolio Assessment (MPA)

Migration Portfolio Assessment (MPA) 是一套評分方法論，將探索資料加上業務背景轉化為每個應用程式的 7Rs 建議與信心分數。MPA 通常在 MAP Mobilize 階段交付。

MPA 評分維度

每個應用程式在多個維度獲得分數：

• 業務關鍵性（Business criticality）（1-5）：停機對營收或營運的影響。
• 技術複雜性（Technical complexity）（1-5）：架構複雜度、有狀態 vs 無狀態、叢集、整合點。
• 雲端整備度（Cloud readiness）（1-5）：與雲端原生模式的距離（12-factor、容器相容、無狀態）。
• 資料重力（Data gravity）：資料量及與其他應用程式的親和性。
• 合規設定檔（Compliance profile）：HIPAA、PCI-DSS、SOX、GDPR 標籤。
• 相依性（Dependencies）：上下游整合點的數量與性質。

MPA 產出

• 每個應用程式的建議 R 及信心分數。
• Affinity group 歸屬（應一起遷移的應用程式群組）。
• 初步 wave 指派。
• 預估遷移工作量（人天）。
• 現代化機會標記（Rehost 後 Refactor 的候選）。

MPA 產出直接饋入 Migration Hub 作為主要 portfolio 記錄，並饋入 wave 規劃器作為排序輸入。

Wave 規劃 — Dependency Graph、Affinity Groups 與 Wave 排序

Wave 規劃是將探索與分類轉化為可執行排程的環節。在 SAP-C02 深度，你必須了解三個基本概念：dependency graph、affinity groups 與 wave 排序規則。

Dependency Graph

每個應用程式是一個節點；每個整合點是一條邊。邊有類型（同步 API、非同步佇列、共用資料庫、共用驗證、檔案共享）與方向（A 呼叫 B、A 寫入 B 的 DB）。Dependency graph 由 Application Discovery Service agent 資料（TCP/UDP 連線觀察）結合業務負責人訪談建立。

考試原則：你無法在其強相依（共用資料庫、驗證服務、訊息代理）就緒之前遷移應用程式。弱相依（分析饋送、唯讀報表）可晚些遷移。

Affinity Groups

Affinity group 是一組必須一起遷移的應用程式，因為它們共用有狀態相依（共用資料庫叢集、共用檔案伺服器、緊耦合訊息匯流排），或因為需要同步切換（帳務 + 發票 + GL 必須在切換瞬間保持一致）。

Affinity group 通常包含 3 到 20 個應用程式，並成為 wave 指派的單位——你將整個群組指派到一個 wave，而非個別 app。

Wave 排序規則

1. Wave 0 — Foundation：Landing zone、共用服務（AD、DNS、監控、日誌、網路）。在 foundation 就緒前，絕不遷移商業 app。
2. Wave 1 — Pilot / 低風險獨立 app：5-15 個獨立、非關鍵且有完整文件的應用程式。驗證遷移工廠運作，建立團隊肌肉記憶。
3. Waves 2-N — 相依性排序的商業波次：對 dependency graph 做拓撲排序；尚無地端相依的 app 優先遷移；有多個地端相依的 app 較後遷移。
4. 最終 Wave — 複雜 / 高風險：大型主機鄰近系統、SAP、Oracle 叢集、高合規工作負載。在團隊最有經驗、模式最成熟時最後遷移。
5. Retire 與 Retain wave：Retire 在探索期間持續進行；Retain 標記複查日期後排除於 wave 之外。

500-App 規模的 Wave 大小與節奏

500-app / 18 個月方案的典型規劃如下：

• 第 0-3 個月：Mobilize、landing zone、探索（Wave 0）。
• 第 3-5 個月：Pilot（Wave 1，約 10 個 app）。
• 第 5-16 個月：商業 wave（Waves 2-12，每 wave 約 40-50 個 app，每月同時進行 2 個 wave）。
• 第 16-18 個月：最終複雜 wave、Retain 集合驗證、資料中心停用。

AWS Migration Hub — Portfolio 視圖與協調

AWS Migration Hub 是 portfolio 規模遷移評估與執行的單一控制台。在 SAP-C02 深度，你必須了解 Migration Hub 整合什麼與協調什麼。

Migration Hub 整合（資料來源）

• AWS Application Discovery Service — 伺服器清查、效能、相依性。
• Migration Hub Strategy Recommendations — 每個 app 的 7Rs 建議。
• AWS Application Migration Service (MGN) — 每台伺服器的 Rehost 狀態。
• AWS Database Migration Service (DMS) — 資料庫遷移任務狀態。
• AWS Migration Hub Orchestrator — SAP on AWS、Windows IIS 及通用遷移模式的工作流程範本。
• 夥伴工具 — Carbonite、CloudEndure（舊版）、Cloudscape、Risc Networks（透過 Migration Hub Import API）。

Migration Hub Orchestrator

Migration Hub Orchestrator 是協調跨服務多步驟遷移程序的工作流程引擎。範例工作流程：

1. MGN：在 AWS 中測試啟動執行個體。
2. DMS：確認資料庫複製延遲 < 30 秒。
3. Route 53：將 TTL 降至 60 秒。
4. MGN：切換至正式目標。
5. DMS：切換複製方向（反向複製，用於回滾安全）。
6. DNS 切換。
7. 切換後驗證測試。
8. MGN：停用源頭伺服器。

Orchestrator 讓這些步驟可在各 wave 間重複使用——你不需要為每個 app 重建 runbook。

Migration Hub Home Region

Migration Hub 有 home region 概念——你選擇一個 AWS region 儲存 portfolio 資料。Strategy Recommendations、Import 與 Orchestrator 都在此 region 運作。實際遷移目標可在任何 region；home region 僅儲存 portfolio 中繼資料。

情境演練 — 500 個 App、12 個資料中心、18 個月截止日

讓我們針對典型 SAP-C02 情境執行完整遷移評估：500 個應用程式分布於 12 個資料中心，18 個月截止日，混合技術棧（Windows、Linux、VMware、Oracle、SQL Server、舊版 Siebel CRM、AS/400 大型主機工作負載）。

步驟 1 — CAF 整備（第 0-1 個月）

與企業領導團隊針對六個 CAF 視角進行 MRA 工作坊。這個規模的組織的典型發現：

• Business：策略對齊（CFO 已支持，需要 ROI 論證）—— 整備。
• People：400 名系統管理員中只有 15% 持有 AWS 認證。缺口 —— 需要 12 個月再培訓計畫與 CCoE 組建。
• Governance：無雲端財務管理工具。缺口 —— 需要 FinOps 職能。
• Platform：無 AWS landing zone。缺口 —— 需要部署 Control Tower。
• Security：現有 SOC 處理地端事務；AWS 原生工具（GuardDuty、Security Hub）未設定。缺口 —— 在 Mobilize 期間補強安全設定。
• Operations：現有 ITIL 型維運；無雲端可觀測性。缺口 —— 補充 CloudWatch / X-Ray。

步驟 2 — MAP Assess → Mobilize 資格（第 1-2 個月）

以 500 個 app 和遷移後預估每年 $800 萬 AWS 花費，此方案明確具備完整 MAP 資格。洽談 AWS Migration Competency 夥伴，簽署 MAP 承諾書，解鎖 Mobilize 資金。

步驟 3 — 探索（第 2-4 個月）

部署 Application Discovery Service Agentless Connector 至全部 12 個 VMware vCenter 取得廣度。對 120 台實體伺服器及前 200 台業務關鍵 VM 部署 ADS Agent 取得程序層級相依性資料。讓探索執行 3-4 週，累積有意義的使用率與相依性資料。

步驟 4 — TCO（第 3-4 個月並行）

將探索資料饋入 Migration Evaluator。產出：

• 地端 3 年 TCO：$8,400 萬（硬體更新、DC 租賃、電力、人員）。
• AWS 目標態 3 年 TCO（75% Rehost + 20% Replatform + 5% Retire/Repurchase/Retain）：$5,200 萬。
• 預估 3 年節省：$3,200 萬，回收期：14 個月。
• 遷移一次性成本：$900 萬（Professional Services + 工具 + 切換人力，部分由 MAP 點數抵扣）。

CFO 簽核。

步驟 5 — MPA 與 7Rs 分類（第 4-5 個月）

對全部 500 個應用程式執行 Migration Portfolio Assessment。典型結果：

• Retire：75 個 app（15%）—— 重複的 wiki、未使用的報表工具、已停用產品線。
• Retain：30 個 app（6%）—— AS/400 大型主機工作負載（廠商雲端方案預計 2027 年推出）、5 個受資料主權法規阻擋的 app。
• Relocate：40 個 app（8%）—— VMware 綁定的舊版系統，無時間進行 re-platform。
• Rehost：280 個 app（56%）—— 大多數標準 Windows/Linux VM。
• Replatform：55 個 app（11%）—— 自管 SQL Server → RDS、自管 PostgreSQL → Aurora、Tomcat → Elastic Beanstalk。
• Repurchase：15 個 app（3%）—— 舊版 Siebel → Salesforce、地端 Exchange → Microsoft 365、自建 HRIS → Workday。
• Refactor：5 個 app（1%）—— 5 個戰略型客戶面向單體，預計在遷移後進行 Strangler Fig 現代化。先 Rehost，Wave 12 後再 Refactor。

步驟 6 — Wave 計畫（第 5 個月）

使用 ADS Agent 資料的 dependency graph，拓撲排序成 12 個商業 wave：

• Wave 0（第 3-5 個月）：Foundation —— landing zone、共用服務帳號、AD、集中式 DNS、日誌。
• Wave 1（第 5-6 個月）：Pilot —— 10 個獨立內部工具。
• Waves 2-11（第 6-16 個月）：商業 wave，每 wave 40-50 個 app，依相依性排序。Affinity group（帳務 + 發票 + GL 為一組 8 個 app；客戶入口 + 驗證 + 個人資料為另一組 12 個 app）一起遷移。
• Wave 12（第 16-17 個月）：複雜 / 高合規 —— Oracle 叢集、HIPAA 工作負載、Siebel → Salesforce 切換。
• 第 17-18 個月：資料中心停用、Retain 集合驗證、遷移後 Well-Architected 審查、現代化積壓啟動。

步驟 7 — 執行與追蹤（第 5-18 個月）

所有 wave 在 AWS Migration Hub 追蹤。MGN 持續複製 Rehost 候選；Orchestrator 執行切換 runbook；DMS 以 CDC 遷移資料庫。每個 app 的即時狀態可在方案辦公室查看。

商業論證與 TCO 建模（Pro 深度）

可信的商業論證是每一塊遷移投資的門檻。在 Pro 深度，商業論證包含四個組成部分：

1. 穩態地端成本

不只是當年成本。你必須納入：

• 硬體更新週期（通常每 4-5 年——攤銷 CapEx 衝擊）。
• 資料中心租賃費用的漲幅（通常每年 3-5%）。
• 電力與冷卻成本趨勢。
• 人員成本（系統管理員、網路工程師、DC 技術員）。
• 軟體授權真實成本（Oracle、SQL Server、VMware、Windows Datacenter）。

2. AWS 目標態成本

使用 Migration Evaluator 建模：

• 右尺寸 EC2（非地端過度佈建規格的一對一對應）。
• Reserved Instances / Savings Plans 假設（通常穩定工作負載 70% 覆蓋）。
• Replatform 目標的受管服務節省。
• 資料傳輸成本建模（egress、跨 region、跨 AZ）。
• 儲存類別優化（S3 IA、冷儲存用 Glacier）。

3. 一次性遷移成本

• Professional Services（夥伴 + AWS ProServe）。
• 工具（MGN、DMS、DataSync —— 大多免費但適用計量資料傳輸費用）。
• Snow Family 離線資料傳輸（若適用）。
• 切換人力（內部團隊 + 承包商）。
• 培訓與認證投資。
• MAP 點數抵扣。

4. 業務效益（超出成本節省）

• 敏捷性：上市時間改善、預計新增營收。
• 風險降低：DR 改善、安全態勢提升。
• 永續性：碳足跡降低（AWS 公布各 region 的碳強度）。

治理、方案辦公室與變革管理

遷移評估不在 wave 計畫完成後結束——執行需要持續治理。

方案辦公室（遷移辦公室）

一個專責團隊，負責：

• Migration Hub portfolio 完整性。
• Wave 排程與風險登記冊。
• 夥伴與廠商協調。
• 主管層級狀態報告。
• MAP funding 里程碑追蹤。

治理護欄

• SCPs 在 OU 層級套用（每個 wave OU 或每個業務單位 OU）以防止偏差。
• Control Tower Account Factory 確保每個遷移業務單位的 landing zone 一致性。
• AWS Config rules 用於合規強制執行。
• AWS Budgets 為每個 wave / 每個業務單位設定警示。

變革管理與培訓

• CCoE 作業模型 —— 雲端工程卓越中心，負責模式、培訓與內部諮詢。
• Cloud fluency 培訓 橫跨 IT 人員（100% 取得 AWS Cloud Practitioner、技術人員取得 Solutions Architect Associate、平台團隊取得 Specialty 認證）。
• 利益相關人溝通計畫 —— 業務負責人在其 app 的 wave 前收到簡報；切換 runbook 在切換日前先行演練。
• 切換後支援 —— 超高警戒期（Hypercare，通常 2 週），提升隨叫隨到覆蓋。

SAP-C02 遷移評估常見陷阱

陷阱 1 — 混淆 CAF 與 Well-Architected Framework

CAF 是組織轉型（遷移前/中，橫跨 6 個視角）。Well-Architected 是每個工作負載的架構審查（工作負載上到 AWS 後，橫跨 6 個支柱）。SAP-C02 喜歡在題幹中同時提到兩者——仔細辨別「全組織轉型」（CAF）vs「特定工作負載架構」（WAF）。

陷阱 2 — 混淆 Migration Evaluator 與 Pricing Calculator

500-app portfolio 商業論證：Migration Evaluator。單一新架構的假設估算：Pricing Calculator。考試常把兩者放在同一組答案選項中。

陷阱 3 — 跳過 Mobilize

情境說「公司想下個月開始遷移」。考生直接選 Migrate 階段。錯誤——沒有 Mobilize（landing zone、CCoE、試行 wave），遷移一定失敗。正確答案通常包含一段短暫的 Mobilize 衝刺，才進入 Wave 1。

陷阱 4 — 混淆 Relocate 與 Rehost

兩者感覺都像 lift-and-shift。Relocate = hypervisor 層級（VMware Cloud on AWS），保留 vSphere。Rehost = OS 層級（EC2），使用 MGN，離開 vSphere。若題幹提到「保留 VMware 運作方式」，答案是 Relocate。若提到「移至 EC2」，答案是 Rehost。

陷阱 5 — 在遷移視窗內進行 Refactor

在 500-app 規模的 18 個月資料中心退場視窗內，Refactor 幾乎不可能完成。Pro 等級的答案通常是先 Rehost、後 Refactor 作為現代化 wave。留意試圖 Refactor 所有 app 的答案選項——它們通常是錯的。

陷阱 6 — 假設完整探索覆蓋是強制要求

在 Pro 深度，不一定需要對每台伺服器安裝 agent。Agentless 可覆蓋 VMware 環境 80% 的資產。強制推送 agent 到每一台伺服器會延遲探索數週，並使維運團隊反感。正確答案需在覆蓋率與實際可行性之間取得平衡。

FAQ — Pro 深度遷移評估與 7Rs

Q1：MAP Mobilize 與 Migrate 階段有何差異？

MAP Mobilize 是準備階段——landing zone、詳細探索、MPA、CCoE 組建、試行 wave（5-15 個 app）、詳細商業論證。MAP Migrate 是執行階段——大規模 wave 執行、資料中心停用、遷移後 Well-Architected 審查。Mobilize 以 MAP Assess 簽核為前提；Migrate 以 Mobilize 完成與試行成功為前提。SAP-C02 情境常問某項活動屬於哪個階段——landing zone 建置是 Mobilize，資料中心停用是 Migrate。

Q2：何時使用 Application Discovery Service Agent vs Agentless Connector？

當環境以 VMware 為主且需要快速、低作業負擔的探索時，使用 Agentless Connector。它提供 VM 清查與 VM 層級效能，但不含程序層級相依性。當需要程序層級相依性對應、TCP/UDP 連線資料以取得準確的應用程式間流量地圖，或伺服器不在 VMware 上（實體機、Hyper-V、KVM、雲端）時，使用 Agent。大型遷移通常兩者並用——agentless 取廣度，agent 針對關鍵 app 取深度。

Q3：CFO 要求在核准遷移預算前進行 TCO 比較。該使用哪個 AWS 服務？

AWS Migration Evaluator（前身為 TSO Logic）。Migration Evaluator 吸收地端探索資料（伺服器規格、使用率、軟體清查），結合 AWS 定價、Reserved Instance 與 Savings Plans 假設及受管服務目標架構，產出 CFO 能夠簽核的可信 3 年或 5 年 TCO。AWS Pricing Calculator 用於假設架構估算，而非 portfolio TCO。Migration Evaluator 是 portfolio 規模商業論證的正確答案，也是 MAP funding 資格的門檻。

Q4：如何排序一個有複雜相依性的 500 個應用程式 portfolio 的遷移 wave？

依相依性順序加上風險遞增排序，而非業務關鍵性或應用程式大小。從 Wave 0（foundation） 開始——landing zone 與共用服務。Wave 1（pilot） —— 5-15 個低風險獨立 app，驗證遷移工廠。Waves 2-N（business） —— 對 dependency graph 做拓撲排序，讓應用程式在其強相依遷移後才遷移；以 affinity groups（共用有狀態相依的 app）作為遷移單位。最終 wave —— 複雜 / 高合規 / 大型主機鄰近 app，在團隊最有經驗時最後遷移。業務關鍵性影響的是切換視窗長度與測試嚴謹度，而非 wave 順序。

Q5：哪些條件讓組織有資格申請 AWS Migration Acceleration Program (MAP) funding？

MAP funding 資格通常要求：最低遷移規模（完整 MAP 通常須 1000 台以上伺服器，較小規模可用 MAP-SS 或 MAP for Windows）、承諾的 AWS 花費預測（通常遷移後每年 $1M+ 的循環消耗）、C 級主管贊助、與 AWS Migration Competency 夥伴合作，以及完成 MAP Assess 階段產出物（MRA 報告、方向性 TCO）。MAP Mobilize funding 以 AWS 點數形式提供，抵扣合格的 Professional Services 與工具費用；MAP Migrate funding 更大，以 wave 里程碑為開放條件。小型遷移（低於約 200 台伺服器或預估每年 $50 萬 AWS 花費）通常不具備 MAP 資格，應尋求 APN 夥伴方案或自費遷移。

Q6：5 個戰略型客戶面向單體應用程式應在 18 個月遷移視窗內進行 Refactor 嗎？

不應——在 Pro 深度，正確答案是先 Rehost、後 Refactor。在 18 個月資料中心退場視窗內 Refactor 5 個戰略型單體，會與遷移工廠競爭工程資源，通常導致資料中心退場延遲。建議模式是：在指派的商業 wave 中先 Rehost 單體，按時完成資料中心退場，之後再執行一個專屬的遷移後現代化方案，使用 Strangler Fig 模式（API Gateway 作為前端、逐步以 Lambda + DynamoDB + 容器替換）在後續 12-18 個月推進。遷移評估應將這 5 個 app 標記為 Rehost，附帶 Refactor 現代化積壓，而非遷移期間的 Refactor。

Q7：Migration Hub 與 Application Discovery Service 及 Migration Evaluator 有何不同？

三者互補，並非競爭：

• Application Discovery Service 是技術資料收集器 —— 從地端伺服器以 agentless 或 agent-based 方式收集清查、效能與相依性資料。
• Migration Evaluator 是商業論證引擎 —— 消耗 ADS 資料（或其自有收集器）加上 AWS 定價，產出 portfolio TCO。
• Migration Hub 是 portfolio 視圖與協調器 —— 整合 ADS 資料、Strategy Recommendations、MGN、DMS 與夥伴工具，提供單一控制台的每個 app 狀態追蹤與切換 runbook 執行。

完整的遷移評估使用三者：ADS 收集、Migration Evaluator 驗證、Migration Hub 執行。

Q8：哪個 CAF 視角負責遷移資金與 portfolio 成本控制？

Governance 視角。Governance 的能力包含方案與專案管理、效益管理、風險管理，以及 cloud financial management (CFM)。遷移期間，Governance 負責預算 vs 實際追蹤、FinOps 工具（Cost Explorer、Cost and Usage Reports、Budgets、Cost Anomaly Detection）、回充/展示設計，以及 MAP funding 里程碑報告。不要與 Business 視角（策略對齊）或 Platform 視角（landing zone）混淆。

延伸閱讀與官方來源

• AWS Cloud Adoption Framework (CAF) v3 白皮書：https://docs.aws.amazon.com/pdfs/whitepapers/latest/overview-aws-cloud-adoption-framework/overview-aws-cloud-adoption-framework.pdf
• AWS Migration Acceleration Program (MAP)：https://aws.amazon.com/migration-acceleration-program/
• AWS Migration Hub 使用指南：https://docs.aws.amazon.com/migrationhub/latest/ug/whatishub.html
• AWS Application Discovery Service 使用指南：https://docs.aws.amazon.com/application-discovery/latest/userguide/what-is-appdiscovery.html
• AWS Migration Evaluator：https://aws.amazon.com/migration-evaluator/
• AWS Prescriptive Guidance — Large Migrations：https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/welcome.html
• AWS Prescriptive Guidance — Migration Strategies (7 Rs)：https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• AWS Application Migration Service (MGN)：https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html
• AWS SAP-C02 Exam Guide：https://d1.awsstatic.com/training-and-certification/docs-sap-pro/AWS-Certified-Solutions-Architect-Professional_Exam-Guide.pdf

總結 — 遷移評估 Pro 深度速查表

• CAF 6 視角：Business、People、Governance、Platform、Security、Operations —— 將痛點對應到主要負責視角。
• MAP 3 階段：Assess（值得嗎？）→ Mobilize（準備好了嗎？）→ Migrate（執行）。不可跳過 Mobilize。
• 7Rs 決策矩陣：Retire（無使用）、Retain（有障礙）、Relocate（VMware 搬移）、Rehost（EC2 原樣）、Replatform（受管服務替換）、Repurchase（SaaS）、Refactor（雲端原生重建）。典型 portfolio 比例：10-20% Retire、5-10% Retain、5-15% Relocate、50-70% Rehost、15-25% Replatform、5-10% Repurchase、5% 視窗內 Refactor。
• 探索：Agentless Connector（VMware 廣度，無程序資料）vs Agent（程序層級相依性，任何 hypervisor）。兩者並用。
• Migration Evaluator：Portfolio TCO 引擎，MAP funding 的門檻，CFO 可信商業論證。非 Pricing Calculator。
• MPA：跨關鍵性、複雜度、整備度、相依性的每 app 評分。產出驅動 wave 指派。
• Wave 規劃：Foundation（Wave 0）→ Pilot（Wave 1）→ 相依性排序的商業 wave → 複雜/高合規最後遷移。Affinity group 一起遷移。
• Migration Hub：單一 portfolio 視圖，整合 ADS + MGN + DMS + 夥伴工具，Orchestrator 執行切換 runbook。
• 治理：Control Tower + Organizations SCPs + Config Rules + Security Hub —— 每個 wave 的分層護欄。
• 變革管理：CCoE 組建、cloud fluency 培訓、切換後 Hypercare。

掌握遷移評估，你就掌握了 SAP-C02 考試的 20%（Domain 4）加上 Domain 1（組織複雜性）與 Domain 3（持續改善）的相當大比例。7Rs 決策矩陣、CAF 視角、MAP 階段與 wave 規劃基礎概念，是考試投出的每一道企業遷移題目的核心知識。