大多數雲端遷移專案都從基礎設施掃描開始。 Azure Migrate 會發現虛擬機器。 AWS Application Discovery Service 會對應伺服器。 Google Migration Center 會清點工作負載。幾天之內，團隊就能獲得一份包含每台伺服器、其 CPU 使用率、記憶體佔用以及在目標雲端中運行等效配置的預估成本的電子表格。基礎設施評估完成，可以開始規劃了。
但事實並非如此。因為基礎設施清單只能告訴你應用程序運行在哪些硬件上，而無法告訴你這些應用程序是否能在雲端運行，也無法告訴你遷移到雲端需要多少成本，哪些應用程序存在遷移後會失效的依賴項，哪些應用程序使用的是雲平台不支持的已棄用 API，或者哪些應用程序包含十年未記錄的業務邏輯，而這些邏輯需要在驗證任何轉換之前理解。基礎設施發現是雲端遷移評估的先決條件，但它本身並不是評估。
什麼是雲端遷移評估？
雲端遷移評估是一種結構化分析，用於確定一組工作負載是否可以、如何以及以何種成本遷移到雲端。它為三項決策提供依據：針對每項工作負載採用何種遷移策略、遷移實際需要投入多少人力和雲端支出，以及工作負載應按何種順序遷移以管理依賴性風險。
完整的雲端遷移評估涵蓋五個不同的維度。基礎設施發現工具只能解決其中一個維度的問題。其他四個維度則需要不同的工具、技術和專業知識。
| 評估維度 | 它回答了什麼問題 | 主要工具 |
|---|---|---|
| 基礎建設 | 現有哪些伺服器、虛擬機器和服務？它們的利用率情況如何？ | Azure Migrate、AWS Application Discovery、Google 遷移中心 |
| 應用代碼 | 這段程式碼與雲端目標相容嗎？需要做哪些修改？ | 演員陣容亮點 SMART TS XLCloudPilot、GitHub Copilot 應用現代化 |
| 數據 | 現有數據量是多少？資料儲存在哪裡？遷移的複雜性和合規性限制是什麼？ | AWS 資料庫遷移服務、Azure 資料庫遷移服務、Striim |
| 安全與合規 | 有哪些監理要求？存在哪些安全漏洞？需要對身分識別和存取管理 (IAM) 以及加密技術進行哪些更改？ | AWS Security Hub、Microsoft Defender for Cloud、Prisma Cloud |
| 成本和 TCO | 移民的全部成本是多少？移民後的總擁有成本又是多少？ | AWS 定價計算器、Azure TCO 計算器、基礎設施成本、Apptio 雲端能力 |
僅關注基礎設施層面的組織所製定的遷移計劃範圍不明。他們會在遷移過程中才發現應用程式、資料、安全性和成本的各種問題，而此時解決這些問題的成本也最高。
雲端遷移評估的五個維度
基礎設施評估
基礎設施評估是起點。它清點來源環境：包括每台伺服器、虛擬機器、容器和服務，以及它們的配置、使用率資料和與其他基礎架構元件的依賴關係。
Azure Migrate 或其他類似產品等工具可以自動發現工作負載元件和設定。這些工具可以減少人工操作，並在整個環境中提供一致的資料收集，但它們可能會遺漏未記錄的依賴項。
Azure Migrate是組織遷移到 Azure 的標準工具。它無需代理即可發現 VMware vSphere、Hyper-V 和實體伺服器環境，並在遷移任何工作負載之前產生準備評估、基於效能的資源調整建議和成本估算。
AWS 應用程式遷移服務 (MGN)和AWS 應用程式發現服務在 AWS 目標平台上的功能基本上相同。發現服務透過無代理程式收集或本地安裝的代理來收集本地配置和效能資料。
Google 遷移中心為 Google Cloud 遷移提供統一的發現和評估，將資產清單、依賴分析和 TCO 建模整合到一個控制台中。
基礎架構工具能夠產生：伺服器清單、使用率基準、基礎架構元件之間的網路依賴關係圖，以及針對目標雲層的合理設定建議。但它們無法產生：關於運行在這些伺服器上的應用程式是否與雲端相容、程式碼更改成本，以及這些應用程式中的資料將如何遷移的任何資訊。
應用程式代碼評估
應用程式程式碼評估可以識別可能影響遷移成功的相容性問題和現代化改造機會。此評估對於確保應用程式在 Azure 中可靠運作以及有效規劃遷移階段至關重要。您必須評估應用程式程式碼，以便及早發現障礙、降低遷移失敗的風險並為目標架構決策提供基礎。
應用程式程式碼評估發現了基礎設施掃描無法偵測到的四類問題：
相容性障礙包括目標雲端環境中不存在或行為不同的 API、框架或執行時間功能。例如，基於目標 PaaS 服務中不可用的 Java EE 應用程式伺服器建置的 Java 應用程序，在部署前需要修改程式碼。使用 Windows 特定檔案路徑約定的應用程序，未經修改無法在基於 Linux 的雲端實例上執行。
程式碼中嵌入的硬編碼基礎架構假設，例如 IP 位址、檔案系統路徑、伺服器名稱或連接埠號，在雲端環境中將不再有效。這些都是遷移障礙，任何基礎設施掃描都無法發現它們，因為它們位於應用程式程式碼中，而不是基礎設施配置中。
已棄用的 API 用法，即呼叫目標雲端環境不支援或已被取代的 API、函式庫或平台功能。雲端平台供應商會定期棄用舊版的 API，即使目前運作正常的應用程式在新平台上也會失敗。
依賴關係複雜性，即應用程式的內部結構，決定了遷移的難度以及是否可以將其拆分為可獨立部署的服務。無論基礎設施清單如何顯示，內部耦合度高的單體應用程式比內部耦合度低的應用程式更難遷移，成本也更高。
CAST Highlight可自動執行組合級應用程式程式碼評估，掃描多種語言的原始程式碼，產生雲端就緒度評分、識別障礙並進行開源風險分析。微軟的 Azure 雲端採用框架將其列為非 .NET 和非 Java 工作負載的建議工具。
CloudPilot專注於對雲端就緒情況進行詳細評估，包括 JavaScript、Python、Node.js 和 Go 的兼容性評分和遷移路線圖產生。
GitHub Copilot App Modernization將 CAST 的 AppCAT 評估功能與 AI 輔助程式碼修復相結合，專門針對 .NET 和 Java 工作負載。
對於涵蓋 COBOL、JCL、PL/I、RPG 和其他大型主機語言以及現代技術堆疊的企業環境，這些工具無法覆蓋。對遺留系統進行應用程式程式碼評估則需要完全不同類別的工具。
資料評估
資料評估旨在確定每個待評估資料儲存的複雜性、資料量、合規性要求和遷移方法。它常常被低估，因為乍看之下似乎很簡單，只需遷移資料庫、遷移資料即可，但實際的複雜性卻往往在之後才顯現出來。
數據評估必須回答的關鍵問題：
資料量和吞吐量：現有資料量是多少？變化率是多少？能否在停機時間內完成遷移，還是必須使用連續複製才能實現近乎零停機時間的切換？
模式相容性：目標資料庫服務是否支援與來源資料庫相同的模式特性、資料類型和預存程序？ Oracle 特有的 PL/SQL 結構在遷移到 PostgreSQL 或其他雲端原生替代方案之前需要轉換。
資料主權和合規性：資料依法必須儲存在哪裡？ GDPR、HIPAA、PCI-DSS 和特定行業法規可能會限制哪些雲端區域可以託管特定類別的資料。
應用耦合度：應用程式程式碼與特定資料庫模式的耦合程度如何？技術上簡單的模式變更可能需要對應用程式程式碼進行大量修改才能適應。
AWS 資料庫遷移服務和Azure 資料庫遷移服務支援同構遷移（Oracle 到 Oracle、SQL Server 到 SQL Server）的持續複製，最大限度地減少停機時間，並支援異質遷移（Oracle 到 PostgreSQL、SQL Server 到 Aurora）的架構轉換。
Striim和Attunity為高可用性遷移場景提供即時資料流和複製功能，在這些場景中，資料庫停機時間是不可接受的。
安全與合規性評估
安全評估繪製出每個工作負載目前的安全狀況，並確定為滿足雲端安全標準、合規框架和零信任架構原則所需的變更。
安全評估必須涵蓋以下方面：
身分和存取管理 (IAM)：本機應用程式通常使用具有廣泛權限的服務帳戶和基於密碼的身份驗證。雲端環境則需要基於角色的存取控制、最小權限服務身分以及基於憑證或令牌的身份驗證。目前 IAM 與所需 IAM 之間的差距在於遷移工作，這與基礎設施清單無關。
加密：本地環境和雲端環境對靜態資料和傳輸中資料的加密要求有所不同。在應用層自行管理加密的應用程式需要與雲端密鑰管理服務整合。在私有網路上可接受的未加密資料存儲，在遷移到雲端託管服務之前需要進行加密。
網路安全：在本機網路硬體中實施的防火牆規則、網路分段和流量檢查必須重建為雲端安全群組、虛擬網路配置和雲端原生防火牆規則。
合規框架匹配：每個受監管行業都有特定的合規要求，這些要求與特定的雲端配置相對應。 HIPAA 工作負載需要在儲存、存取日誌記錄和加密方面做出特定的設定選擇。 PCI-DSS 要求進行網路分段，而雲端 VPC 中的網路分段實作方式必須與實體網路基礎架構中的實作方式不同。
Microsoft Defender for Cloud可根據 CIS 基準、NIST、PCI-DSS 和其他框架對 Azure 工作負載進行安全態勢評估和合規性評估。
Prisma Cloud（Palo Alto Networks）和AWS Security Hub提供同等的多雲安全評估和合規性監控。
成本和總擁有成本評估
成本評估是業務利害關係人最直觀的遷移成果，也是最容易出錯的環節。常見的錯誤是將目前本地硬體成本與雲端運算和儲存成本進行比較，這種比較往往不完整且具有誤導性。
完整的總體擁有成本評估包括：
雲端基礎架構成本：目標雲端配置中的運算、儲存、網路和託管服務成本。基於實際使用資料（而非預置容量）進行合理配置，是準確估算與虛高估算之間的關鍵差異。
遷移成本：完成應用程式程式碼變更、資料遷移、安全重新配置和測試所需的工程工時。僅評估基礎設施成本往往會低估這部分成本，因為它們無法了解應用程式的複雜性。
授權變更：從永久本地授權轉向基於雲端的授權模式，或從特定供應商軟體轉向雲端原生替代方案，從根本上改變了授權成本結構。
營運模式變更：管理實體硬體的本地維運團隊被管理雲端服務的雲端維運團隊所取代。技能、工具和人員配置也隨之改變。
培訓和過渡成本：團隊學習新的雲端平台、新的部署模式和新的操作程序會在過渡期間產生生產力成本。
AWS 定價計算器、Azure TCO 計算器和Google Cloud 定價計算器主要針對雲端基礎設施成本維度。 Infracost提供整合到 IaC 管道中的成本估算功能，在 CI/CD 流程中產生成本估算。 Apptio Cloudability和類似的 FinOps 工具則提供遷移後的持續成本可見度。
七項移民策略：評估如何決定適用哪一項
「7R」框架描述了適用於每項工作負載遷移的策略。評估決定了哪種策略最合適，而評估錯誤意味著採用了錯誤的策略，而這正是大多數遷移成本超支的根本原因。
| 策略 | 這是什麼意思 | 評估訊號表明 |
|---|---|---|
| 重新託管 （升降式） | 無需更改程式碼即可遷移到雲端 | 應用複雜度低，無相容性障礙，與基礎架構相容 |
| 重新平台 | 利用雲端服務進行一些小改動（例如，遷移到託管資料庫） | 適度耦合，特定的平台升級機會，可接受的程式碼變更範圍 |
| 重構 | 重新架構以適應雲端原生模式（微服務、容器） | 高單體耦合度、顯著的可擴展性需求，由預期的流量成長所證明。 |
| 重構者 | 對應用程式架構進行了重大重新設計 | 此應用程式與雲端平台存在根本性不相容；新架構帶來重大業務優勢 |
| 重建 | 從頭重寫 | 該設備已無法經濟有效地修復；更換比修復便宜。 |
| 更換 | 棄用客製化應用程序，採用SaaS替代方案 | 該應用程式提供的功能是通用功能，而現有的雲端服務可以更好地滿足這些功能需求。 |
| 退休 | 停用後，該應用程式不再需要。 | 評估過程中發現該應用程式已失效、冗餘或已被取代。 |
基礎設施清單無法區分重新託管、重新平台化、重構和重建這幾種方案，因為它們在基礎設施層面看起來完全相同。只有透過應用程式程式碼評估才能區分它們。
傳統系統和大型主機系統的雲端遷移評估
標準的雲端遷移評估工具是為現代基礎架構設計的，例如虛擬機器、容器、微服務和雲端原生應用程式。但對於大型主機工作負載、運行在 IBM z/OS 上的 COBOL 程式、管理批次的 JCL 作業流程、處理金融交易的 PL/I 應用程式以及嵌入在 AS/400 系統中的 RPG 程序，這些工具的效能很差，甚至完全無效。
大型主機雲端遷移評估需要採用截然不同的方法，因為瓶頸不在於基礎架構層，而在於應用程式程式碼、數十年來累積的業務邏輯、透過共享資料集和副本簿建立的隱式依賴關係，以及基礎設施掃描無法揭示的執行時間行為。
在負責任地規劃任何大型主機遷移之前，需要進行八項分析：程式清單、依賴關係映射、業務邏輯提取、死代碼識別、複雜度分類、批次調度分析、資料品質評估和整合映射。這些分析在大型主機遷移風險降低的背景下進行了詳細描述。每項分析都是代碼級評估活動，而非基礎設施評估活動。
雲端遷移評估工具對比
下表列出了主要的雲端遷移評估工具及其所針對的評估維度和最適用的場景。
| 工具 | 評估層 | 雲端目標 | 最適合 |
|---|---|---|---|
| Azure 遷移 | 基礎建設 | 天藍 | 虛擬機器和伺服器發現、容量調整、Azure 成本估算 |
| AWS 應用程式發現服務 | 基礎建設 | AWS | 用於 AWS 遷移的本機伺服器發現 |
| Google 遷移中心 | 基礎建設 | GCP | GCP遷移的資產清單和總擁有成本 |
| CAST 亮點 | 應用代碼 | 多雲 | 跨語言的組合規模代碼就緒度評分 |
| CloudPilot | 應用代碼 | 多雲 | 對 Python、JS、Node.js 和 Go 進行詳細的兼容性分析 |
| SMART TS XL | 應用程式程式碼 + 依賴關係映射 | 多雲 | COBOL、JCL、大型主機和多語言組合分析 |
| AWS數據管理系統 | 數據 | AWS | 資料庫遷移及模式轉換 |
| Azure 資料庫遷移服務 | 數據 | 天藍 | SQL Server、MySQL、PostgreSQL 遷移到 Azure |
| 斯特里姆 | 數據 | 多雲 | 即時複製實現零停機資料遷移 |
| 適用於雲端的 Microsoft Defender | 安全性 | Azure/多雲 | 安全態勢和合規性評估 |
| Prisma 雲 | 安全性 | 多雲 | 在 AWS、Azure 和 GCP 上實現 CSPM 和合規性 |
| 基礎設施成本 | 價格 | 多雲 | CI/CD 管線中整合 IaC 的成本估算 |
| Apptio 可云性 | 價格 | 多雲 | 財務營運和持續的雲端成本管理 |
| Corent SurPaaS | 基礎設施 + 應用 | 多雲 | 人工智慧驅動的發現、評估與遷移編排 |
SMART TS XL 對應用程式程式碼進行雲端遷移評估
SMART TS XL 針對基礎設施工具無法觸及的應用程式碼評估層，特別適用於應用組合跨越多種語言、平台和技術世代的企業和傳統環境。
對於包含 COBOL 程式、JCL 作業流程、Java 服務、Python 管道和 SQL 模式的遷移程序， SMART TS XL 同時建構一個跨所有組件的統一依賴模型。在遷移團隊決定哪些元件需要重新託管、哪些元件需要重構以及哪些元件需要棄用之前， SMART TS XL 規定：
完整的程式清單：環境中每種語言的每個原始程式、副本、流程和模式，實際清單，而不是文檔化的清單，在遺留環境中，兩者通常會有 20-30% 的偏差。
跨語言依賴關係映射：應用程式依賴關係映射功能追蹤 COBOL 程式如何連接到 DB2 模式，Java 服務如何查詢該模式，進而為 Python 管道提供數據，最終產生供現代 React 前端使用的輸出。這種跨語言依賴關係鏈決定了遷移順序，具有大量依賴項的元件必須在所有依賴項準備就緒後才能遷移。
死代碼識別：從未被任何生產執行路徑呼叫的程式和過程可以完全排除在遷移範圍之外。在大型遺留環境中，這通常佔總量的 10% 到 25%，在評估階段即可大幅降低成本。
複雜度分類：靜態程式碼分析功能會根據圈複雜度、副本依賴項數量、呼叫次數以及其他決定遷移難度的指標對每個程式進行分類。高複雜度且呼叫者眾多的程式適合重構或重建。低複雜度、低依賴項的程式適合重新託管。
變更前的影響分析：影響分析功能可以在任何遷移活動開始之前回答“如果此程序發生變更，將會影響什麼？”，將未知風險轉化為結構化的、列舉的範圍。
對於計劃將大型主機遷移到雲端的組織而言， SMART TS XL“ 遺產現代化 分析結果產生了遷移供應商在轉換工作開始之前所需的遷移前評估：完整的結構清單、依賴關係圖、複雜性分類和死代碼排除報告。
完整的雲端遷移評估應該產生哪些結果
評估的價值取決於它所能促成的決策。一份完整的雲端遷移評估報告應包含五個成果，共同構成遷移方案：
應用組合清單及遷移策略分配：範圍內的每個應用程式都進行重新託管、重新平台化、重構、重新架構、重建、替換或退役分類，並提供支援每種分類的評估證據。
基於依賴關係的遷移計劃：應用程式的遷移順序，基於依賴關係圖而非任意分組。沒有來自其他在遷移範圍內的應用程式的入站依賴項的應用程式可以在早期遷移階段進行遷移。而依賴許多其他應用程式的應用程序，則在其依賴項準備就緒後，在後續的遷移階段進行遷移。
遷移總成本估算：工程工作量、遷移工具成本、臨時並行運作成本和培訓成本，而不僅僅是基礎設施成本差異。
遷移後總擁有成本模型：基於適當的配置和實際利用率資料預測的雲端支出，與目前的本地營運成本進行比較，並對授權變更和營運模式轉型做出合理的假設。
風險登記冊：已識別的風險、相容性障礙、複雜的資料遷移、未記錄的依賴項、合規性限制，以及每項風險的機率、影響和建議的緩解措施。
在遷移開始前完成這五項交付成果的組織，將擁有成功實施遷移專案所需的全部資訊。而那些跳過應用程式程式碼評估、資料評估或安全評估的組織，其交付成果的版本往往不完整，需要在遷移過程中才能發現缺少的部分，而每次發現問題都會增加成本。
