COBOL 仍運行著約 95% 的 ATM 交易、80% 的線下 POS 機交易，以及全球大多數主要銀行、保險公司和政府機構的核心處理邏輯。儘管已有六十多年的歷史，COBOL 每天處理的交易額仍高達約三兆美元，如此龐大的交易量使得現代化成為企業最重要的 IT 決策之一。行動的壓力迫在眉睫：COBOL 開發人員的退休速度正在加快，合規性要求日益增長，而與雲端、API 和 AI 環境的整合需要架構上的變革，而基於回呼的大型主機系統從未設計支援這些變革。
選擇合適的現代化合作夥伴決定了轉型能否帶來更快、更易於維護的系統，還是會造成耗時多年、成本失控且有穩定性風險的專案。本次對比的供應商涵蓋了從擁有數千名 COBOL 專家的全球系統整合商到提供自動化轉換流程的專業工具公司。它們在方法、商業模式、目標產業以及最擅長的具體現代化策略方面各不相同。以下比較表格、供應商簡介和成本指南旨在幫助您進行直接評估，而非僅供一般了解。
COBOL 現況：目前應用、勞動力以及現代化的迫切性
COBOL 並非一種正在消亡的語言；它面臨的是日益嚴重的 COBOL 人才危機。如今，活躍的 COBOL 開發人員的平均年齡已超過 55 歲，而電腦科學專業的畢業生中，學習 COBOL 的比例不足百分之一。 IBM 估計，目前有超過 200 億行 COBOL 程式碼正在生產環境中運作。 美國勞工統計局項目 未來幾年，COBOL專家的數量將持續下降。延後現代化的組織不僅無法維持穩定，反而會隨著剩餘COBOL專家的退休而逐年累積勞動風險。
同時，COBOL 系統在其設計用途方面依然表現出色。在批量處理、大容量交易處理以及受監管環境下的資料完整性等方面，基於 COBOL 的大型主機系統仍然以相近的成本優於許多現代替代方案。因此，進行現代化改造的理由很少是“COBOL 系統已經崩潰”，而幾乎總是“我們無法以足夠快的速度維護、擴展或整合 COBOL 系統以滿足當前需求”。如今仍在使用 COBOL 的公司包括摩根大通、美國銀行以及美國社會安全署等，這些機構一旦現代化改造失敗，將面臨營運和監管方面的嚴重後果，因此風險管理成為選擇任何現代化改造合作夥伴的首要標準。
COBOL程式設計師短缺也帶來了另一個方面的緊迫性：企業越來越難以招募到能夠閱讀、擴展或調試現有COBOL程式碼的開發人員，這意味著即使是維護現有系統也變得越來越困難。因此，文件工具、程式碼理解平台和知識轉移專案在現代化市場中正蓬勃發展。
COBOL現代化在實務上的意義
現代化並非單一行動。根據組織的目標、風險承受能力和時間安排，它可以採取幾種不同的形式，這些形式在成本、風險和結果方面存在根本差異。
| 策略 | 怎麼了 | 最適合 | 風險等級 |
|---|---|---|---|
| 平台重構 | COBOL 程式碼可在 Linux、Windows 或雲端直接運作。 | 無需重寫即可快速遷移到雲端平台 | 低 |
| 重構/重寫 | 將 COBOL 轉換為 Java、.NET、Python 或雲端原生應用 | 長期可維護性，現代技能 | 高 |
| API封裝 | 透過 REST/SOAP API 公開 COBOL 邏輯 | 延長使用壽命，雲端集成 | 低 |
| 託管服務 | 供應商運作大型主機環境 | 營運卓越模式，避免內部專業知識缺口 | 媒材 |
| 漸進式遷移 | 絞殺榕方法，模組隨時間遷移 | 大型複雜系統，零停機時間 | 媒材 |
| 人工智慧輔助轉換 | LLM 工具可將 COBOL 程式碼產生目標語言程式碼 | 加快重構吞吐量 | 中等偏上 |
大多數大型企業會同時採用多種策略，例如將風險最高的 COBOL 邏輯封裝成 API，將較不重要的批次程式重構為 Java，並將基礎架構遷移到雲端託管的大型主機環境。供應商的選擇必須與具體的策略組合相匹配，而不僅僅是「現代化」這一總體目標。
COBOL 到 Java 的遷移
在金融服務和保險業，COBOL 到 Java 的重構是最常見的路徑。 Java 擁有強大的生態系統支援、豐富的開發人員資源以及原生雲移植性。挑戰在於結構層面：COBOL 的隱式十進制處理、OCCURS DEPENDING ON 可變長度表以及 REDEFINES 子句在 Java 中沒有直接對應的實現，而且自動轉換工具產生的 Java 程式碼雖然技術上正確，但往往難以閱讀和維護。對於這條路徑，最佳供應商要麼在轉換後的程式碼清理方面投入巨資，要麼提供能夠產生真正符合慣用 Java 語言習慣而非僅僅是 COBOL 原始碼語法鏡像的工具。正如分析中所探討的… 跨語言靜態程式碼分析理解跨語言邊界的資料流和欄位關係是大規模安全重構的先決條件。
COBOL 到 .NET 和 C# 的遷移
在歐洲市場以及以 Microsoft Azure 作為雲端平台的組織中，COBOL 到 C# 的遷移十分常見。 C# 與 COBOL 有一些共同的結構特徵，使得轉換過程較為容易：強型別、顯式十進制運算、記錄式資料結構等特性使得轉換相對容易。專注於此領域的供應商包括 Advanced（前身為 Modern Systems）以及幾家大型歐洲系統整合商。 COBOL 到 .NET 轉換的成功案例通常來自保險和政府機構，這些機構的原始 COBOL 程式碼結構良好，而目標環境是基於 Windows 的雲端環境。
COBOL 遷移到雲端：平台重構還是重構
平台遷移到雲端和重構到雲端之間的差異至關重要。平台遷移是指將 COBOL 程式碼基本上保持不變地遷移到雲端託管環境中，可以使用 AWS 大型主機現代化服務、Google 的產品或託管大型主機供應商，同時保留 COBOL 執行環境。這種方法速度更快、風險更低，並且能夠保留所有現有行為。重構到雲端則是將 COBOL 程式碼轉換為雲端原生語言（通常是 Java 或 Python），並圍繞容器、微服務和雲端託管資料庫重建架構。 AWS、埃森哲和 Astadia 專注於平台遷移，而 Advanced、TSRI 和 vFunction 則更專注於向雲端原生架構進行重構。
頂級 COBOL 現代化供應商：簡介、評分和真實評價
以下供應商按市場影響力排序，從全球最大的系統整合商到專業領域專家。每家供應商的簡介均包含來自 G2、TrustRadius 和 PeerSpot 的評分、已驗證評論的客戶直接評價，以及該供應商最適合的組織類型的明確說明。如果您發現有供應商遺漏或希望提出更正建議，請聯絡我們：marketing@www.in-com.com
OpenText（以前稱為 Micro Focus Enterprise Suite）
OpenText 於 2023 年收購了 Micro Focus，因此獲得了業界最全面的 COBOL 工具鏈之一。 Visual COBOL、Enterprise Developer 以及應用程式現代化和連接套件支援依賴關係映射、API 啟用、跨平台編譯和增量重構。此工具鏈可在 Windows、Linux 和雲端環境中運行，使企業能夠在不重寫程式碼的情況下重新部署 COBOL 工作負載，並透過 REST API 逐步開放功能。
官方網站： OpenText 企業開發人員 | 評分： G2 Visual COBOL 4.1/5 · G2 應用現代化 4.2/5 · PeerSpot評分：4.2/5
客戶回饋：
- 「Micro Focus Visual COBOL 最棒的地方在於它能與各種關係型資料庫管理系統 (RDBMS) 集成，並且能夠跨作業系統部署。它有助於高效地實現大型機現代化。」—高級軟體工程師，2022 年
- 「為資深和新晉 COBOL 開發人員提供有用的模板和工具。與現代技術棧集成良好。」——敏捷教練，2022
- 「COBOL 程式碼非常容易偵錯和編輯，並且可以在 Windows、Unix 或 Linux 系統上運行。」 ，分析師，2022 年
最適合： 對於那些既想保留 COBOL 語言又想獲得雲端可移植性和 API 連接性的組織而言，這種方案尤其重要。它尤其適用於受監管的環境，因為在這些環境中，重寫程式碼會帶來過高的風險。
埃森哲
埃森哲的大型主機現代化業務規模與其整體諮詢業務相匹配：擁有全球交付團隊、行業專屬框架，並與AWS、微軟和IBM等公司建立了合作夥伴關係。其「大型主機零遷移」方法利用敏捷和DevSecOps流程管理過渡，幫助客戶徹底擺脫大型主機硬體。埃森哲在銀行和保險領域特別強大，曾為多家全球知名機構成功交付大規模COBOL遷移專案。
官方網站： 埃森哲大型主機現代化 | 評分： G2 4.0 / 5 · TrustRadius 6.4/10 · Gartner同行見解
客戶回饋：
- “經驗豐富的顧問提供可靠且注重整合的支持，幫助實現關鍵專案目標。”，助理經理，2023年
- “埃森哲在系統整合和全球推廣管理方面表現出色，但跨時區溝通在營運上可能面臨挑戰。”，首席架構師，2023
最適合： 需要進行端到端轉型和業務流程重組的大型企業。埃森哲的規模使其更適合進行多年期、跨系統的項目，而非孤立的現代化項目。
IBM 諮詢與 IBM Z / LinuxONE
IBM 創造了大型主機和 COBOL 運行時環境，其諮詢部門仍然是希望在保留大型主機功能的同時添加現代介面的企業進行現代化改造的最權威專家。 IBM Z 和 LinuxONE 為需要與容器化應用程式並行運行的 COBOL 工作負載提供企業級環境，而 IBM 諮詢則透過 API 啟用、Kafka 事件流以及與 AWS 和 Azure 的混合雲集成，實現分階段轉型。
官方網站： IBM Z 和 LinuxONE · IBM 諮詢 | 評分： G2 4.0 / 5 · TrustRadius IBM Z 8.4/10 · PeerSpot評分：4.3/5
客戶回饋：
- “IBM Z 提供無與倫比的性能和可靠性，使其成為現代化改造的堅實基礎，同時還能運行關鍵工作負載。”，高級架構師，銀行業，2023 年
- 「IBM顧問公司幫助我們將API與原有的COBOL系統集成，從而無需完全遷移即可更快地交付新服務。”，首席資訊官，保險業，2023年
- 「該平台強大且安全，但現代化服務成本高昂，需要仔細規劃才能實現投資回報率。」—政府IT總監，2022年
最適合： 適用於希望在不取代 COBOL 運作時的情況下，對 COBOL 系統的介面和整合層進行現代化改造的組織。尤其適合對行為回歸零容忍的銀行和政府機構。
阿斯塔迪亞
Astadia 是一家專注於大型主機到雲端遷移的專業公司，擁有完善的方法論和固定成本的商業模式。其「大型主機到雲端工廠」方案提供可重複使用的藍圖，用於將 COBOL 和批次工作負載遷移到 AWS、Azure 和 Google Cloud，並專注於自動化，以減少手動操作和切換風險。 Astadia 的客戶包括擁有龐大 COBOL 環境的金融服務機構和正在對關鍵任務系統進行現代化改造的政府機構。
官方網站： 阿斯塔迪亞 | 評分： G2 4.2 / 5 · TrustRadius 7.9/10 · PeerSpot評分：4.2/5
客戶回饋：
- 「Astadia 提供了一條從 COBOL 大型主機到 AWS 的清晰且結構化的遷移路徑，並設定了明確的里程碑和交付成果。”，首席技術官，銀行業，2023 年
- 「他們的固定成本模式讓我們對預算規劃充滿信心，而他們的自動化系統則最大限度地減少了切換期間的停機時間。」—政府IT總監，2022年
- 「該專案執行順利，雲端整合度高，但知識轉移方面需要額外的研討會。”，保險業首席資訊官，2022年
最適合： 致力於按計劃進行雲端遷移的組織。 Astadia 可預測的商業模式和自動化重點適合將 COBOL 遷移到 AWS 或 Azure 的中大型企業。
TSRI（軟體革命公司）
TSRI 是最專業的自動化 COBOL 轉換供應商之一，擁有自主研發的工具集，可將 COBOL 程式碼及相關批次邏輯轉換為 Java、C# 或 Python 程式碼。該公司專注於生成可維護的目標程式碼，而非 COBOL 原始碼的語法鏡像，並透過轉換後優化，使生成的 Java 或 C# 程式碼更符合語言習慣，而不僅僅是功能等效。 TSRI 已為眾多金融機構、政府機構和保險公司提供轉換服務，其 COBOL 代碼量從數十萬行到數千萬行不等。
官方網站： 台研所 | 評分： G2 ~4.1/5 · TrustRadius評分約為7.5/10 · 點對點
顧客回饋（經G2和TrustRadius驗證的評價）：
- 「TSRI 的自動化轉換產生的 Java 程式碼，我們的開發人員能夠真正閱讀和維護，這與我們評估過的其他工具相比，是一個顯著的優勢。”，銀行工程副總裁，2023 年
- “轉換準確率很高，團隊在測試和切換過程中提供了強有力的支持，甚至發現了我們內部團隊遺漏的極端情況。”，某保險公司IT總監，2022年
- “TSRI按時按預算完成了項目，而且最終的代碼庫所需的返工量比我們根據之前的轉換嘗試預期的要少。”，政府項目負責人，2022年
最適合： 對於那些既重視輸出結果的可維護性又重視功能等效性的組織而言，TSRI 是實現 COBOL 到 Java 或 COBOL 到 C# 自動化轉換的理想選擇。 TSRI 最適用於結構良好、資料定義清晰且動態調用邏輯有限的 COBOL 程式碼。
vFunction
vFunction 是一個基於人工智慧的現代化平台，它能夠分析單體應用（包括基於 COBOL 的系統），並識別出可提取為微服務的領域限定元件。 vFunction 並非逐行轉換 COBOL 程式碼，而是映射應用的資料存取模式和交易邊界，從而產生反映實際業務領域的微服務架構。該平台可與現有的 CI/CD 管線集成，並在程式碼庫演進過程中提供持續分析。
官方網站： vFunction | 評分： G2 4.3 / 5 · TrustRadius 7.8/10 · Gartner同行見解
客戶回饋：
- “vFunction 為我們提供了一張清晰的架構圖，我們利用這張圖來確定優先提取哪些 COBOL 模組，它消除了我們規劃中的猜測成分。”，金融服務行業架構副總裁，2023 年
- 「該平台的分析能夠準確識別限界上下文，但對 COBOL 特有的深度解析仍需人工補充審核。”，軟體架構師，保險業，2022 年
最適合： 當組織從單體 COBOL 架構遷移到微服務架構時，vFunction 的優勢最為顯著，尤其是在目標是架構分解而非語言轉換的情況下。
火箭軟件
Rocket Software 專注於 IBM Z 和 OpenVMS 環境的現代化工具。其產品組合包括 Rocket D3、Rocket MultiValue 以及企業級資料庫現代化工具，可協助企業將與 COBOL 相關的資料結構遷移到現代資料庫，同時保留應用程式邏輯。 Rocket 在資料庫遷移和資料整合方面特別強大，並透過與 Jenkins、Git 和現代 CI/CD 管線的集成，為大型主機環境提供 DevOps 支援。
官方網站： 火箭軟件 | 評分： G2 4.0 / 5 · TrustRadius 7.6/10 · PeerSpot評分：4.1/5
客戶回饋：
- 「Rocket 的資料庫遷移工具在處理我們的 VSAM 到關係型資料庫轉換時，其準確度甚至超過了我們手動重寫所達到的水平。」—資料庫架構師，銀行業，2023 年
- “大型主機 DevOps 整合工具不錯，但針對特殊情況的文件可以更詳細一些。”，政府部門 DevOps 工程師，2022 年
最適合： 專注於大型主機資料庫現代化、VSAM 到關聯式資料庫遷移以及現有 COBOL 環境的 DevOps 賦能的組織。
高級（以前稱為現代系統）
Advanced 專注於將 COBOL 和其他傳統語言的程式碼自動轉換為 Java、C# 和雲端原生環境。其方案涵蓋完整的遷移流程：語言轉換、資料庫從 IMS 和 VSAM 遷移到關係型系統，以及與雲端託管基礎架構的整合。 Advanced 以產生易於維護的輸出程式碼和提供遷移後最佳化而著稱，使轉換後的程式碼庫能夠滿足現代開發團隊的需求。
官方網站： 高級（以前稱為現代系統） | 評分： G2 4.2 / 5 · TrustRadius 7.8/10 · PeerSpot評分：4.2/5
客戶回饋：
- “Advanced 提供了高度自動化的 COBOL 到 Java 遷移方案，減少了人工編碼錯誤，加快了部署速度。”，某銀行 IT 副總裁，2023 年
- 「他們的現代化框架提供了清晰的依賴關係分析，並能準確地將資料庫轉換為 SQL，這使得整合更加容易。」—政府 IT 總監，2022 年
- 「專案按時完成，轉換後的應用程式更易於維護，儘管我們還需要進行一些性能方面的調整。”，零售業首席資訊官，2022年
最適合： 為尋求具備強大資料庫遷移支援的自動化語言轉換方案的企業量身打造。最適合擁有龐大 COBOL 系統且目標語言明確的組織。
塔塔諮詢服務（TCS）
TCS憑藉其規模優勢和專有的自動化技術，為COBOL現代化改造帶來巨大潛力。其MasterCraft和TransformPlus框架可自動執行程式碼分析、測試用例產生和遷移，從而顯著減少大規模轉換中的人工工作量。 TCS在銀行、保險和政府部門領域尤其強大，已為擁有數千萬行COBOL代碼的客戶成功交付了分階段的現代化改造專案。
官方網站： 塔塔諮詢服務公司 | 評分： G2 4.0 / 5 · TrustRadius 7.5/10 · PeerSpot評分：4.0/5
客戶回饋：
- 「TCS分階段實現了COBOL系統的現代化改造，透過自動化減少了測試和程式碼重構方面的人工工作量。”，IT經理，銀行業，2023年
- “技術深度和領域專業知識都很紮實，但新團隊的學習曲線可能比較陡峭。”，公共部門首席資訊官，2022年
最適合： 對於擁有複雜 COBOL 環境的大型企業而言，TCS 的規模優勢對於多年期專案而言是優勢，但對於需要快速迭代的組織而言則是一種限制。
印孚瑟斯
Infosys 將其 Cobalt 雲端框架應用於 COBOL 現代化改造，將傳統系統遷移與更廣泛的雲端原生應用相結合。該公司在依賴關係發現、合規驅動的分階段遷移以及 COBOL 業務邏輯的 API 賦能方面實力雄厚。 Infosys 在受監管行業的交付方面尤其備受讚譽，在這些行業中，現代化流程的治理和可審計性與技術執行同等重要。
官方網站： 印孚瑟斯 | 評分： G2 4.1 / 5 · TrustRadius 7.6/10 · PeerSpot評分：4.1/5
客戶回饋：
- “Infosys 提供了一份結構化的 COBOL 現代化路線圖，其中包含清晰的里程碑和可衡量的結果。”，銀行業專案總監，2023 年
- “技術執行和自動化程度很高，但大型專案需要密切協調，才能使離岸和在岸團隊步調一致。”，首席技術官，保險業，2022年
最適合： 金融服務和電信業的組織需要符合合規要求、有條不紊且具有強大治理能力的現代化計劃。
DXC技術
DXC Technology 在大型主機管理領域擁有數十年的經驗，並將這種深厚的營運實力應用於現代化改造。其優勢在於風險管理型轉型，特別關注批次完整性、事務可靠性和切換計畫。 DXC 最適合那些將穩定性和可預測性置於速度之上的組織，其託管服務能力意味著它可以在逐步現代化的同時，維持大型主機環境的正常運作。
官方網站： DXC技術 | 評分： G2 3.8 / 5 · TrustRadius 7.0/10 · PeerSpot評分：4.0/5
客戶回饋：
- “DXC為我們COBOL和JCL工作負載的平穩過渡提供了支持，他們提供了可靠的切換計劃和持續的穩定性保障。”，金融服務項目經理，2023年
- 「他們在大型主機遷移方面擁有豐富的經驗，但交付時間可能會因資源分配情況而有所不同。」—某製造業IT總監，2022年
最適合： 對於那些營運連續性和批量可靠性不容妥協，並且能夠接受在現代化改造的同時建立長期管理服務關係的組織而言，這無疑是理想之選。
凱捷
凱捷的 COBOL 現代化實踐在將現代化作為更廣泛的數位轉型計畫的一部分時最為有效。公司將技術遷移與業務流程重組相結合，確保 API 啟用和雲端採用能夠帶來實際的業務價值，而不僅僅是技術改進。凱捷尤其適合零售、金融和政府客戶，因為這些產業的現代化計畫必須在確保系統穩定性的同時，產生可衡量的業務成果。
官方網站： 凱捷 | 評分： G2 4.0 / 5 · TrustRadius 7.4/10 · PeerSpot評分：4.0/5
客戶回饋：
- “凱捷提供了一套分階段的現代化改造方案，並與我們的混合雲環境實現了深度集成。”，首席資訊官，銀行業，2023年
- “他們擁有卓越的專業知識，並且能夠將現代化目標與我們的業務策略相結合。”，零售業IT總監，2022年
最適合： 對於正在進行數位轉型和 COBOL 現代化的組織而言，業務協調和混合雲端整合與技術執行同樣重要。
認識到
Cognizant專注於程式碼現代化和產品組合優化，幫助企業在進行全面遷移之前，確定哪些COBOL應用程式需要現代化改造、哪些需要淘汰以及哪些需要用API封裝。這種產品組合最佳化的視角使Cognizant區別於那些在未評估每個應用程式的轉換是否為正確方案之前就執行轉換的供應商。
官方網站： 認識到 | 評分： G2 4.1 / 5 · TrustRadius 7.2/10 · PeerSpot評分：4.0/5
客戶回饋：
- “Cognizant 幫助我們清理並優化了 COBOL 應用組合，減少了重疊和技術債務。”，金融服務業 IT 經理，2023 年
- “顧問們知識淵博、靈活應變，成功地將API整合到我們的原始系統環境中。”，醫療保健行業首席資訊官，2022年
最適合： 擁有龐大且異質應用組合的組織，必須同時規劃合理化與現代化。
AWS Mainframe Modernization
AWS 大型主機現代化是一項託管服務，可提供將 COBOL 應用程式自動遷移到 AWS 託管執行時間環境的方案，並提供重構工具將 COBOL 轉換為 Java，以實現雲端原生部署。 AWS 與 Astadia、埃森哲和專業的 COBOL 供應商合作，提供完整的方案。 AWS 平台的優點在於其與 AWS 服務（包括 RDS、S3、Step Functions 和 Lambda）的原生集成，從而建構遷移後的架構。
官方網站： AWS Mainframe Modernization | 評分： G2 AWS 4.5/5
最適合： 對於已承諾使用 AWS 且傾向以超大規模雲端平台作為現代化基礎的組織而言，AWS 大型主機現代化方案在目標架構為雲端原生架構而非重新託管的大型主機環境時效果最佳。
傳家寶計算
Heirloom Computing 提供雲端原生 COBOL 執行階段環境，使現有的 COBOL 應用程式無需語言轉換即可在 AWS、Azure 或 GCP 上運行。其平台即服務 (PaaS) 模式意味著 COBOL 程式無需修改即可在容器中運行，從而獲得雲端的可擴展性和營運優勢，而無需承擔轉換專案的風險。對於需要雲端經濟效益但又不想承擔轉換風險的組織而言，Heirloom 提供了一個獨特的解決方案。
官方網站： 傳家寶計算 | 評分： G2 ~4.1/5 · 點對點
最適合： 對於希望立即獲得雲端基礎設施優勢，但又不想承擔語言轉換專案的時間成本和風險的組織而言，這無疑是一個理想的選擇。尤其適用於 COBOL 邏輯穩定且易於理解的應用情境。
精確地（以前稱為 GT 軟體）
Precisely 為大型主機環境提供資料整合和現代化工具，尤其擅長跨 COBOL 和大型主機資料結構的資料存取、元資料管理和企業級搜尋。其工具支援 COBOL 程式的 API 啟用以及與現代資料平台的集成，使其成為專注於資料現代化和應用現代化的企業的理想選擇。
官方網站： 精確地 | 評分： G2 4.1 / 5 · TrustRadius 7.4/10 · PeerSpot評分：4.0/5
最適合： 以資料可存取性和集成為主要現代化目標的組織，而不是完全重寫應用程式的組織。
供應商對比概覽
| 供應商 | 主要方法 | 強度 | 目標尺寸 | 雲平台 |
|---|---|---|---|---|
| OpenText / Micro Focus | 平台重構、API封裝 | COBOL 工具深度 | 全部 | AWS、Azure、GCP |
| 埃森哲 | 全面轉型 | 全球規模，銀行業 | 企業 | AWS、Azure、GCP |
| IBM | 混合現代化 | 大型主機專業知識 | 企業 | IBM 雲端、AWS、Azure |
| 阿斯塔迪亞 | 雲端遷移（平台重構） | 固定成本藍圖 | 中大型 | AWS、Azure、GCP |
| 台研所 | 自動轉換 | 可維護的輸出程式碼 | 中大型 | 任何 |
| vFunction | 微服務分解 | 架構分析 | 中大型 | 任何 |
| 火箭軟件 | 資料庫、DevOps | VSAM遷移 | 全部 | IBM Z、AWS |
| 進階功能 | 自動轉換 | 全端遷移 | 中大型 | 任何 |
| TCS | 分階段計劃 | 規模化、自動化 | Large | 亞馬遜雲、Azure |
| 印孚瑟斯 | 受控移民 | 合規與治理 | Large | AWS、Azure、GCP |
| DXC | 託管服務 | 穩定性、連續性 | Large | 多雲 |
| 凱捷 | 業務轉型 | 數字對齊 | 企業 | 亞馬遜雲、Azure |
| 認識到 | 投資組合合理化 | 應用組合 | Large | AWS、Azure、GCP |
| AWS 大型主機 | 雲端平台遷移 | AWS原生集成 | 全部 | AWS |
| 傳家寶 | 雲端運行時環境 | 零轉換風險 | 全部 | AWS、Azure、GCP |
| 精確地 | 資料整合 | 元數據、數據訪問 | 全部 | 多平台 |
COBOL現代化文件、知識轉移和開發人員入職培訓
COBOL現代化進程中成長最快的需求之一並非轉換本身，而是文件編寫：即如何讓那些並非COBOL系統編寫者、甚至可能不懂COBOL的開發人員也能理解現有的COBOL系統。擁有數千個程式、未編寫文件的副本以及數十年來積累的業務邏輯的組織，隨著經驗豐富的COBOL開發人員退休，正面臨知識轉移危機。正如分析中所探討的… COBOL 中小企業知識轉移退休開發人員所擁有的隱性知識通常是現代化計畫中最關鍵、記錄最少的資產。
解決這問題的工具和方法可分為三類。
自動文件生成 工具解析 COBOL 原始程式碼，並產生人類可讀的程式結構、資料流、段落邏輯和副本依賴關係文檔，而無需手動輸入。 SMART TS XLOpenText 和該領域的幾款專業工具可以產生交叉引用報告、資料字典和呼叫圖，使開發團隊能夠從結構上了解他們以前從未參與過的程式。
代碼可視化 它將 COBOL 程式、JCL 作業、副本簿和資料庫表之間的依賴關係轉換為可瀏覽的圖表。開發人員無需閱讀數千行原始程式碼，即可直觀地探索系統架構，識別哪些程式從何處呼叫、哪些副本簿在多少個程式之間共享，以及哪些資料元素流經哪些執行路徑。 SMART TS XL“ 程式碼視覺化 依賴關係映射功能是專門為此用例設計的。
開發者入職平台 Swimm 等軟體提供動態文檔，隨著程式碼的變更而保持同步，使新開發人員能夠了解程式碼本身及其上下文，而不是依賴幾週內就會脫離實際情況的靜態文檔。
能夠在不遺失文件的情況下實現 COBOL 系統現代化的平台，越來越多地與轉換工具一起作為完整現代化工具鏈的一部分進行評估。在對共享副本或資料庫模式進行更改之前，能夠準確追蹤哪些程式會受到影響，這種能力既能降低現代化風險，又能同時加快開發人員的上手速度。正如在…中所述 大型應用程式的依賴關係圖 分析、繪製組件互連圖是安全管理系統中變更的基礎，而這些系統的發展已經超出了任何個人的全部知識範圍。
COBOL現代化改造成本：預算與預期效益
成本是 COBOL 現代化領域最受關注的議題之一，也是文件透明度最低的議題之一。成本範圍非常廣泛：對結構良好的 COBOL 程式進行有針對性的自動化轉換，每行程式碼的成本可能在 1 到 3 美元之間；而針對複雜的大型機環境，包括評估、轉換、測試、切換和遷移後穩定化在內的全方位轉型服務，每行程式碼的成本可能高達 10 到 25 美元甚至更高。因此，一個包含一百萬行程式碼的 COBOL 系統，其成本可能在一百萬美元到兩千五百萬美元之間，具體取決於策略、供應商、複雜性和時間安排。
主要成本驅動因素包括：
COBOL程式碼的複雜度。 結構良好的 COBOL 程式碼，具有清晰的資料定義和明確的 CALL 關係，其轉換成本遠低於使用動態 CALL、資料定義程式名稱、大量 REDEFINES 子句或嵌入在執行流程中的彙編模組的程式。複雜性評估是任何可靠的現代化專案的首要交付成果，也是準確成本估算的基礎。
策略已選定。 短期內，將 COBOL 運行時遷移到雲端通常是成本最低的選擇。將語言轉換為 Java 或 C# 雖然前期成本較高，但可以降低長期維護成本。 API 封裝的初始成本最低，但它只是延緩而非消除底層技術債。
測試和驗證範圍。 對於銀行或保險業的大批量交易系統，測試必須證明其在原始 COBOL 程序的所有輸入範圍內行為一致。這通常是轉換過程中最昂貴的部分，有時甚至超過轉換本身的成本。
遷移後穩定化。 系統切換後的前六個月通常需要供應商提供大量支持，以解決測試期間未發現的極端情況。這一階段的成本和持續時間與遷移前依賴關係分析和測試設計的品質密切相關。
COBOL 到 Java 的遷移成本估算最為常見，原因顯而易見：Java 是最常用的目標語言，而且轉換過程也較成熟，因此可以得到較可靠的估算範圍。對於中型企業（COBOL 程式碼量在 5 萬到 500 萬行之間），使用自動化工具進行 COBOL 到 Java 的轉換成本通常在每行 3 到 8 美元之間；而採用服務主導的轉換方式，則每行成本在 8 到 15 美元之間。 COBOL 到雲端的遷移成本也大致相同，平台重構的成本較低，而程式碼重構的成本較高。
面向銀行和金融服務的 COBOL 現代化
銀行業和金融服務業是全球COBOL工作負載最集中的產業。大多數大型銀行的核心銀行系統、支付處理引擎、結算平台和監管報告系統都基於COBOL運行，因此，這些系統的現代化改造所面臨的挑戰與COBOL系統整體現代化改造所面臨的挑戰有著顯著的不同。
最受好評的 COBOL 銀行系統替代供應商是那些對特定限制有直接經驗的供應商：實時結算要求不能容忍十進制運算中的行為退化，監管報告義務要求從源數據到每次轉換都有可追溯性，消除 24/7 全天候數字銀行服務的批處理窗口，以及每天處理數百萬筆交易的系統零停機切換要求。
IBM、埃森哲、塔塔諮詢服務公司 (TCS) 和印孚瑟斯 (Infosys) 是最常被推薦給大型全球銀行機構的供應商，因為在這些機構中，規模、治理和監管深度比轉換速度更為重要。 Astadia 和 Advanced 則更常被中型金融服務客戶選擇，因為在這些客戶中，明確的範圍、固定成本模式和更快的交付週期是主要選擇標準。專門推薦用於金融服務業 COBOL 現代化改造的供應商，均能始終如一地證明其符合 DORA、巴塞爾協議 III/IV 數據沿襲要求，並能夠提供分階段遷移，確保核心系統在整個過程中持續運行。
金融服務領域的 COBOL 現代化解決方案也越來越需要人工智慧輔助的程式碼理解。 IBM Watsonx Code Assistant for Z 和 GitHub Copilot 的大型主機擴充程式正被越來越多的大型銀行評估為加速 COBOL 分析和 Java 程式碼產生的工具。早期用戶報告稱，人工智慧程式碼產生可以縮短生成初始 Java 程式碼草稿所需的時間，但生成的程式碼在投入生產之前需要經過大量的專家審核，特別是對於包含複雜資料結構或嵌入式 SQL 的程式。
COBOL應用程式的CI/CD和DevOps
現代 COBOL 開發並不一定意味著與大型主機隔離的開發。以 COBOL 應用的 CI/CD 管線工具正日益普及，其需求主要來自那些希望在大型主機開發中應用敏捷實踐，而無需等待全面現代化改造的組織。以 COBOL 應用的現代 CI/CD 的主要供應商包括：
IBM z/OS 開發人員 它與 Visual Studio Code 集成，並為 COBOL 提供基於 Git 的原始碼管理、自動化建置管道和單元測試框架，與現代開發團隊用於 Java 或 Python 的框架類似。
博通公司的ISPW 是一款專為 z/OS 環境設計的發布管理和管線工具，可與 Jenkins、GitHub Actions 和其他 CI/CD 編排器整合。
Rocket Software 的 DevOps 套件 為 IBM Z 提供管道工具，將 COBOL 編譯和單元測試連接到現代管道基礎架構。
OpenText 的企業開發人員 支援在 Windows 和 Linux 上對 COBOL 進行測試驅動開發，讓開發人員在與現代開發工作流程類似的 IDE 環境中編寫和執行 COBOL 單元測試。
在不遺失文件的情況下實現 COBOL 系統現代化的平台也與此相關：CI/CD 與交叉引用和影響分析工具的整合可確保每次程式碼變更都伴隨依賴關係模型的自動更新，從而使文件隨著程式碼庫的演進而保持最新。
AI驅動的COBOL現代化：工具與實際預期
AI 輔助的 COBOL 現代化將在 2025 年和 2026 年從實驗階段過渡到生產工具階段。其主要用例包括程式碼理解（用簡單的英語解釋 COBOL 程式的功能）、程式碼產生（將 COBOL 翻譯成 Java 或 Python）以及測試生成（產生涵蓋 COBOL 程式處理的所有輸入的測試案例）。
IBM Watson X Code Assistant for Z 是該領域經過企業驗證最多的 AI 工具，專為 COBOL 到 Java 的轉換而構建，其模型基於 IBM 大型機碼模式訓練而成。它不會自動產生可用於生產環境的 Java 程式碼：而是產生一個 Java 程式碼草稿，由經過培訓的開發人員進行審查、完善和最終完成。但與手動轉換相比，它能顯著縮短產生該草稿所需的時間。
GitHub Copilot、Claude 和其他通用 AI 程式碼助理也能處理 COBOL 程式碼，但它們在大型機碼模式方面的訓練不如 IBM 的產品那麼專業。使用通用 AI 進行 COBOL 現代化改造的組織表示，它最適用於程式碼解釋和文件生成，而不是直接轉換。
目前，Java 和 COBOL 現代化最準確的程式碼產生來自特定領域的工具，而不是通用的 LLM：IBM watsonx Code Assistant for Z 目前在 COBOL 到 Java 的轉換方面處於領先地位，而 TSRI 的專有工具對於需要高轉換精度和最少後處理的組織仍然具有競爭力。
SMART TS XL 支援 COBOL 現代化改造前、改造中和改造後
SMART TS XL 本部分闡述了分析和規劃階段，決定了現代化專案能否成功或超出預算。在任何轉換工具或供應商開始轉換 COBOL 系統之前，團隊需要了解 COBOL 系統的實際內容：有多少個程序，哪些程序之間相互調用，哪些副本在多少個程序之間共享，哪些程序訪問哪些數據庫表，以及哪些數據通過文件、隊列和共享存儲從一個程序流向另一個程序。
如果沒有這種結構化的知識，現代化供應商只能進行估算，而無法進行範圍界定。有了這種知識，現代化專案的首要交付成果就是依賴關係圖，它清楚地展示了需要轉換的內容、轉換順序以及每個階段需要驗證的內容。這份依賴關係圖也為開發人員所需的知識轉移奠定了基礎：任何新開發人員在參與任何專案時，都可以了解其完整的依賴關係，而無需按順序閱讀每個相關專案。
SMART TS XL 它能夠攝取 COBOL 程式、JCL 作業流程、副本簿、SQL 模式以及程式間的 CALL 關係，並建立統一的交叉引用模型。它能夠識別可在轉換開始前消除的無用代碼，從而縮小轉換範圍並降低成本。它還能識別依賴項數量高的程序，這些程序在切換過程中風險最高，以便相應地分配測試資源。 企業搜索 此功能使開發人員能夠在幾秒鐘內（而不是幾個小時）找到整個應用程式組合中特定欄位、段落或副本成員的每一次使用情況。
这 遺產現代化 的能力 SMART TS XL 透過遷移本身擴展了這一點：隨著程式的轉換，交叉引用模型追蹤哪些程式已轉換，哪些程式仍在 COBOL 中運行，以及哪些程式依賴於兩種狀態下的程序，從而確保已轉換元件和未轉換元件之間的整合是明確的，而不是假定的。
常見問題
COBOL現代化改造要多少錢？ 根據策略和複雜程度，每行程式碼的價格在 1 美元到 25 美元之間。自動化平台遷移成本最低；包含測試和遷移後支援的全方位語言轉換服務成本最高。一個包含 500,000 萬行程式碼的 COBOL 系統，根據具體方案，可能需要花費 500 萬美元到 7.5 萬美元。
COBOL現代化專案需要多長時間？ 針對獨立應用程式的定向轉換需要 3-12 個月。涉及核心銀行或政府系統的企業級專案通常需要 2-5 年，分階段交付，以確保生產系統在整個過程中持續運作。
COBOL現在還在使用嗎？ 是的。據估計，COBOL 每天處理價值三兆美元的金融交易。如今，各大銀行、保險公司和政府機構都在積極運作和維護 COBOL 系統。問題不在於 COBOL 是否被使用，而是各組織能否在不進行大規模現代化改造的情況下維護和擴展該系統。
最佳的 COBOL 現代化解決方案是什麼？ 沒有絕對的最佳解決方案。最佳方案取決於組織的具體目標：OpenText/Micro Focus 適用於低風險的平台重構；Astadia 或 AWS 適用於雲端遷移；TSRI 或 Advanced 適用於自動化語言轉換；IBM 或埃森哲適用於大型企業轉型專案。
哪些供應商最適合銀行業 COBOL 現代化改造？ IBM、埃森哲、塔塔諮詢服務公司 (TCS) 和印孚瑟斯 (Infosys) 服務於大型全球機構。 Astadia、Advanced 和 TSRI 服務於中型金融服務客戶。所有公司都必須證明其符合金融業數據沿襲和審計要求。
COBOL系統能否在不完全重寫程式碼的情況下與雲端和人工智慧整合？ 是的。 API封裝透過REST API將COBOL業務邏輯暴露出來，供現代應用程式使用。遷移到雲端託管的COBOL運行時（例如OpenText、Heirloom）無需轉換即可享受雲端經濟效益。 IBM Watson X和其他AI工具正在與運作中的COBOL環境集成，以增強分析和推薦功能。
COBOL現代化改造有哪些文檔工具？ SMART TS XLOpenText Enterprise Developer、Swimm 以及一些廠商專有工具可以從 COBOL 原始碼自動產生文件。功能最全面的工具可以產生交叉引用報告、呼叫圖、資料流程圖以及涵蓋整個應用程式組合的欄位層級使用圖。
