那些承諾「貼上 COBOL，得到 Java」的工具，產出的是能夠編譯的程式碼。這是容易的部分。困難的部分在於它們看不到的程式碼。
請考量一支電匯處理程式。它包含一個 COMPUTE 陳述式，使用一個名為 TRN-LIMIT的變數。AI 編碼助理將該陳述式轉譯成 Java 的 BigDecimal 運算。程式碼順利編譯。單元測試通過。
在使用者驗收測試（UAT）中，第一筆交易就讓資料庫一致性檢查崩潰。
事後剖析： TRN-LIMIT 並未定義在 AI 所轉譯的來源檔案中。它定義在一個 copybook 裡，而該 copybook 在執行鏈中早於此處數千行被引入。那個 copybook 含有一個 REDEFINES 子句——這是一種 COBOL 結構，可讓同一個記憶體位址依據在完全不同模組中設定的旗標，被解讀為兩種不同的資料型別。
AI 把 TRN-LIMIT 看成一個單純的數值欄位，並假設它是標準整數型別。但在大型主機上，那個記憶體位址存放的是壓縮十進位數（COMP-3）。該 Java 應用程式將毀損的二進位資料寫入資料庫欄位，觸發了參照完整性失敗。
程式碼在語法上完美無瑕。失敗源於脈絡盲點。AI 漏掉了一個存在於其視野範圍之外的相依關係。
單支 COBOL 程式可能參照 40 個以上的 copybook。每個 copybook 又可能 COPY 其他 copybook。變數定義在引入鏈中可能深達 5 層。以文字為基礎的 AI 工具完全看不到這些。
您的 COBOL 並非獨立執行。CA-7 或 TWS 排程 2,000 至 5,000 個帶有相依鏈的 JCL 作業。作業 A 寫入一個資料集，作業 B 在凌晨 2 點讀取。若遷移了 COBOL 卻漏掉 JCL，正式環境就會在午夜當機。
COBOL 的 COMP-3 壓縮十進位數在 Java 中沒有對應型別。Java 的 double 會引入浮點捨入誤差。即使是 BigDecimal ，也需要明確設定捨入模式（HALF_EVEN）才能符合 COBOL 的 ROUNDED 子句。一分錢的差錯會在數百萬筆交易中累積放大。
如今每家主要技術供應商都在銷售大型主機現代化方案。以下說明各家實際交付的內容，以及尚存的缺口所在。
| 供應商／取徑 | 其功能 | 典型成本 | 其遺漏之處 |
|---|---|---|---|
| IBM Watsonx Code Assistant for Z | 搭配 ADDI 相依分析的代理式（agentic）COBOL 轉 Java 轉譯。多代理架構（Orchestrate、Architect、Code 代理）。支援 PL/I 與 IMS。 | 200 萬美元以上（企業授權＋ z/OS 需求） | ADDI 在 z/OS 上執行，導致遷移期間的供應商鎖定。剖析器難以處理 COBOL-85 標準前的舊式結構（如 ALTER 陳述式）。無行為等價測試。無 JCL 相依對映。 |
| Anthropic Claude Code | AI 驅動的程式碼分析、文件產生、相依對映。在探索與探勘階段表現強勁。支援漸進式遷移與 API 包裝。 | 依用量計費的 API 定價 | 通用型 AI。無內建的知識圖譜可用於遞移相依解析。未處理 JCL 排程、行為等價測試或法遵稽核軌跡。 |
| Microsoft Azure Migration Factory | 透過 Semantic Kernel 的模組化代理式代理。COBOL Expert ＋ Java Expert 代理。以 Java Quarkus 為目標。Azure Copilot 遷移代理處於預覽階段。 | Azure 用量＋顧問費 | 目標平台受 Azure 鎖定。開源代理為參考實作，並非可用於受監管環境的正式版本。對 CICS／IMS 支援有限。 |
| DXC Technology | 已取得專利的自動程式碼轉換（COBOL／RPG／JCL 轉 Java）。數十年的大型主機專業。混合雲＋大型主機即服務模式。 | 100 萬至 1,000 萬美元以上 | 專有工具，轉換邏輯透明度有限。聚焦大型企業。18 至 36 個月的合作時程很常見。 |
| TCS／Infosys／Accenture | 具備專有框架（MasterCraft、Cobalt）的大型系統整合商業務。龐大的交付團隊。端對端專案管理。 | 50 萬至 500 萬美元以上 | 以平台為中心的取徑。他們實施供應商工具，而非打造客製化智慧。大型系統整合商合作模式的額外開銷。曾有一家系統整合商主導一項 10 億澳元的銀行遷移案，歷時 5 年並使預算翻倍。 |
| Micro Focus（OpenText）Visual COBOL | 在 .NET／JVM 上原生執行 COBOL。務實的「絞殺榕（strangler fig）」起點。COBOL 編譯器市場領導者。 | 20 萬至 50 萬美元授權費 | 這不是現代化，而是重新託管（rehosting）。COBOL 邏輯仍是 COBOL。技術債依然存在。並未解決人力問題。 |
| 以開源 AI 自行打造（DIY） | XMainframe LLM（70 億／105 億參數，在 COBOL 上比 DeepSeek 好 30%）。Tree-sitter 剖析。客製化管線。 | 工程時間＋基礎設施 | 需要深厚的 COBOL ＋圖譜工程專業。沒有任何正式等級的 COBOL 剖析器能涵蓋所有 IBM Enterprise COBOL v6.x 結構。將剖析器缺口築入根基的風險極高。 |
五項能力，每一項都針對現代化工具鏈中的特定缺口。我們是供應商中立的：無論您的目標是 AWS、Azure、GCP 或地端 Java，知識圖譜都能運作。
我們將您的 COBOL 原始碼、copybook、JCL 程式庫、DB2 目錄匯出、CICS 交易定義以及 IMS 區段階層擷取進一個統一的圖形資料庫。每個變數、每條 PERFORM 鏈、每個 REDEFINES 子句、每項批次相依都會成為一條明確的圖譜邊。當複雜的遞移閉包查詢主導使用情境時，我們會採用 Neo4j；當即時遍歷速度對互動式探索很重要時，則採用 Memgraph。
在擷取過程中，圖譜每天約處理 20 萬至 30 萬行。對於一個 200 萬行程式碼（LOC）的程式碼庫，從首次擷取到完成驗證、可供查詢的圖譜，預計需要 8 至 12 週。其產出是一項永久資產：您的程式碼庫化為可搜尋的拓撲，而非難以解讀的文字檔。
在任何程式碼轉譯開始之前，我們會就四個面向執行圖譜分析：耦合分數（有多少其他模組相依於此模組）、REDEFINES／COMP-3 密度（存在多少資料型別陷阱）、死碼百分比（通常占程式碼庫的 20-30%），以及批次排程關鍵性（哪些 JCL 作業會在何時觸及此模組）。
其產出是一個用於絞殺榕遷移的抽取排序排名。耦合度最低、資料型別最單純的模組最先抽取。被 50 個以上其他模組呼叫的「神級程式（God programs）」最後抽取。這項排序正是受控推出與連鎖崩潰之間的差別。
我們的轉譯代理在產生每個 Java 模組之前，會先查詢知識圖譜，拉取完整的相依遞移閉包。代理能看見位於三層目錄之外 copybook 中的 REDEFINES 子句。它能看見決定捨入行為的壓縮十進位定義。它產生的 Java 使用明確的參數傳遞（相依注入），而非 COBOL 的隱式全域狀態。接著它在沙箱中編譯、執行行為等價測試並自我修正。
我們會依模組複雜度選用最合適的基礎模型。對於直接了當的 PERFORM 轉方法轉換，較小的模型就能勝任。對於含巢狀 REDEFINES、需要將控制流程攤平的 GOTO 義大利麵式程式碼，或內嵌 EXEC CICS 交易邏輯的模組，我們會引入現有最強大的模型，並以完整的圖譜脈絡加以增強。
這是多數供應商略過、也是多數遷移失敗的環節。我們打造一套三層驗證系統：由圖譜推導的控制流程路徑所產生的符號化單元測試；以擷取的正式環境交易進行黃金資料集重播，並以一分不差的精準度逐欄位比對；以及並行正式環境執行——讓兩套系統並行處理實際交易 30 至 90 天，之後才將大型主機模組除役。
金融計算需要使用搭配 HALF_EVEN 捨入模式的 BigDecimal，以符合 COBOL 的 ROUNDED 子句。日期計算則需要以世紀視窗邏輯處理 COBOL 的 6 位日期格式（YYMMDD）。我們將這些轉換規則築入測試框架，而非築入在品質保證（QA）階段才臨時發現的補丁中。
我們將您的 JCL 作業網路、CA-7／TWS／Control-M 相依鏈以及批次處理序列剖析進知識圖譜。每個 JCL 作業都會成為一個節點，並具有指向其所執行 COBOL 程式、其讀寫資料集、以及其所相依排程條件（時間觸發、資料集可用性、前置作業完成）的邊。
當一個 COBOL 模組遷移到 Java 時，我們會同時在您的目標協作平台（Apache Airflow、AWS Step Functions、Azure Data Factory，或分散式環境上的 Control-M）中建構等價的排程。相依鏈會被保留，並與原始的 CA-7／TWS 定義進行驗證比對。一家典型的中型銀行有 2,000 至 5,000 個 JCL 作業。我們全都見識過。
逐步說明以圖譜為基礎的相依解析如何防範最常見的遷移失敗模式。
剖析器處理 PROG-WIRE-01.cbl，遇到 COPY CB-ACCT-LIMITS，並沿著引入鏈追溯。它為每個變數宣告建構抽象語法樹（AST）節點，包括那些巢狀深達 3 層 copybook 中的宣告。
圖譜引擎建立邊： PROG-WIRE-01 → IMPORTS → CB-ACCT-LIMITS。 TRN-LIMIT → REDEFINES → TRN-LIMIT-ALPHA。 LIMIT-TYPE-FLAG → CONTROLS_TYPE_OF → TRN-LIMIT。這捕捉到一項事實： TRN-LIMIT 的資料型別取決於另一個欄位中的執行期旗標。
圖譜向外遍歷：還有哪些其他程式也 COPY 了 CB-ACCT-LIMITS？哪些程式設定了 LIMIT-TYPE-FLAG？哪些 JCL 作業執行那些程式，又以何種順序執行？結果是一條完整的影響鏈。改變 TRN-LIMIT 的轉譯方式，會影響此鏈中的每一支程式。
當轉譯代理處理 PROG-WIRE-01時，GraphRAG 不僅取回原始檔案，還取回 copybook 定義、REDEFINES 關係、旗標欄位，以及所有設定該旗標的程式。代理產生一個採用型別安全聯合（union）模式的 Java 類別：一個 TransactionLimit 物件，會在將底層位元組解讀為 BigDecimal （壓縮十進位模式）或 String （字母模式）之前先檢查旗標。
若沒有圖譜： AI 會假設 TRN-LIMIT 是一個單純的數值欄位，在 Java 中產生一個 long ，於是第一筆電匯就毀損了資料庫。 有了圖譜： AI 能看見完整的相依鏈，並產生可正確處理兩種解讀的型別安全程式碼。這正是一項在 UAT 中可行的遷移，與一項在正式環境中可行的遷移之間的差別。
四個階段，每個階段都有明確的交付成果。我們不會報出一個 3 年的時程然後消失無蹤。每個階段都會產出您所擁有、且可獨立運用的成品。
交付成果：評估報告＋初步知識圖譜原型
交付成果：可查詢的知識圖譜＋抽取排序排名＋影響分析工具
交付成果：已上線的遷移後 Java 模組＋更新後的知識圖譜＋排程等價物
交付成果：經驗證的正式環境部署＋法規文件套件＋更新後的圖譜
回答關於您環境的七個問題。此評估會找出您的整備程度，以及在展開遷移合作之前（無論是否與 Veriprajna 合作）需要處理的具體阻礙。
對於一個具典型複雜度的 200 萬行 LOC 程式碼庫（IBM Enterprise COBOL v6.x、DB2 內嵌 SQL、500 個以上 copybook），圖譜建構需時 8 至 12 週。前 3 週為剖析器設定與驗證。COBOL 方言的差異夠大，因此我們需要在擷取整個程式碼庫之前，先驗證剖析器能處理您對 REDEFINES、OCCURS DEPENDING ON 以及 EXEC CICS／SQL 區塊的特定用法。
第 4 至第 8 週為自動化擷取、實體抽取與關係對映。剖析器每天約處理 20 萬至 30 萬行，但瓶頸在於實體解析，具體而言是判定程式 A 中的 ACCT-NUM 與 copybook CB-ACCT-01 中的 ACCT-NUM 是同一個變數。
第 9 至第 12 週為遞移閉包計算與驗證。我們執行圖譜完整性檢查：每個 PERFORM 目標都必須解析到某個段落，每個 COPY 陳述式都必須解析到某個 copybook，每個 DB2 資料表參照都必須對映到某個結構描述定義。缺口會被標記以供人工審查。產出是一個可查詢的知識圖譜，您可以提出像是「如果我更改 CB-GLOBAL-01 中的 INTEREST-RATE 會發生什麼事？」這樣的問題，並取得一條橫跨所有直接或遞移參照它的程式的完整影響鏈。
可以，而且我們強烈建議如此。絞殺榕模式是大型主機遷移中唯一具備已證實成功紀錄的取徑。整體重寫之所以有 70-80% 的失敗率，是因為它們試圖同時替換一切，從而製造出單一的巨大失效點。
採用絞殺榕取徑時，知識圖譜會找出哪些模組的耦合分數最低，亦即來自其他模組的入向相依最少。這些就是您的抽取候選對象。我們通常從批次報表模組，或那些從 DB2 讀取但不更新共享狀態的獨立計算常式開始。新的 Java 服務與大型主機並行執行。正式環境流量會就該特定功能被導向新服務，而大型主機則繼續處理其餘一切。在將 COBOL 模組除役之前，您會以真實的正式環境資料驗證行為等價性。
多數組織在第一年抽取 15 至 20 個模組，將 MIPS 耗用降低 20-30%，並產生足夠的成本節省以資助下一階段。知識圖譜讓這變得安全，因為它會向您展示每次抽取的波及範圍。如果模組 A 被其他 47 支程式呼叫，那它就不是您的首選抽取候選對象。如果模組 B 被 2 支程式呼叫且從 1 個 DB2 資料表讀取，就從那裡開始。
這是多數現代化專案在進行 6 至 12 個月後撞上意外失敗的層面。您的 COBOL 程式並非孤立執行。它們由 CA-7、TWS（Tivoli Workload Scheduler）或 Control-M 所管理的 JCL 作業流協作。一家典型的中型銀行有 2,000 至 5,000 個帶有複雜相依鏈的 JCL 作業：作業 A 必須在作業 B 開始前完成，作業 C 僅在每月最後一個營業日執行，作業 D 觸發一筆更新某 VSAM 檔案的 CICS 交易，而該檔案由作業 E 讀取。
我們將 JCL 與 COBOL 一同剖析進同一個知識圖譜。每個 JCL 作業都會成為一個節點，並具有指向其所執行 COBOL 程式、其讀寫資料集、以及其所相依排程條件的邊。當我們將一個 COBOL 模組遷移到 Java 時，我們會同時在您的目標平台中建構等價的排程，無論那是 Apache Airflow、AWS Step Functions 或 Azure Data Factory。相依鏈會被保留，並與原始版本進行驗證比對。
我們見過程式碼遷移完美成功，但正式環境卻因為沒有人對映那個每晚凌晨 2 點執行前置處理步驟的 CA-7 作業而崩潰的專案。
IBM Watsonx Code Assistant for Z（目前為 v2.8.20，Project Bob 將於 2026 年稍晚推出）是一款具備深度大型主機整合的強大產品。它需要 IBM ADDI（Application Discovery and Delivery Intelligence）來建立其相依分析，而 ADDI 在 z/OS 上執行。這意味著您的相依分析工具就駐留在您正試圖遷離的那台大型主機上。這也意味著 IBM 掌控分析層，從而在遷移最關鍵的階段製造出供應商鎖定。
我們的知識圖譜在大型主機之外執行。我們擷取原始碼匯出、JCL 程式庫、DB2 目錄匯出以及 copybook 儲存庫。圖譜駐留在您的雲端環境或地端基礎設施中，獨立於 IBM 授權之外。其次，Watsonx 聚焦於 COBOL 轉 Java 轉譯。我們則先聚焦於理解，再聚焦於轉譯。知識圖譜是一項永久資產，在遷移完成很久之後，仍可服務於影響分析、文件產生與架構治理。
第三，ADDI 的 COBOL 剖析器對於 COBOL-85 標準之前的結構（特別是 ALTER 陳述式與某些巢狀 REDEFINES 模式）有已記載的限制。我們會為每個客戶的方言打造客製化的剖析器擴充。
最後，IBM 的定價鎖定大型企業。我們的合作模式則適用於中型機構——那些無法在預算中容納一筆 200 萬美元以上 IBM 合作案的機構。
行為等價性正是多數 AI 輔助遷移崩潰之處。能夠編譯並通過單元測試的程式碼，仍可能因為壓縮十進位捨入差異、EBCDIC 轉 ASCII 編碼不一致，或無法轉譯為 Java 物件的 REDEFINES 記憶體覆疊語意，而產生錯誤結果。
我們打造一套三層驗證框架。第 1 層是符號等價性：我們從知識圖譜產生單元測試，涵蓋原始 COBOL 控制流程中的每一個分支，包括負金額、除以零的防護，以及閏年日期計算等邊界情況。第 2 層是黃金資料集重播：我們從大型主機擷取一組具代表性的正式環境交易（輸入記錄、DB2 讀取、CICS 互動），並透過新的 Java 服務重播它們。輸出會逐欄位比對。對於金融計算，我們使用搭配 HALF_EVEN 捨入的 BigDecimal 來驗證一分不差的精準度，以符合 COBOL 的 ROUNDED 子句行為。
第 3 層是並行正式環境執行：兩套系統同時並行處理相同的實際交易 30 至 90 天。差異會被記錄、調查並修正，之後才將大型主機模組除役。這是最漫長的階段，但也是能捕捉那些在 30 年正式環境中累積、任何測試套件都無法完全預料到的邊界情況的階段。
DORA（數位營運韌性法案，Digital Operational Resilience Act）自 2025 年 1 月 17 日起已全面生效，並直接衝擊任何運行大型主機系統的歐盟受監管金融實體。第 11 條要求 ICT 風險管理框架須納入定期的韌性測試，以及基於真實世界攻擊情境、以威脅為導向的滲透測試。多數大型主機環境並非為這類測試而設計。您無法在不付出可觀授權與基礎設施成本的情況下，輕易地建置一個複製的 z/OS 環境來執行滲透測試。
DORA 同時要求詳盡的 ICT 資產清冊、在特定時限內的事件通報，以及對關鍵 ICT 服務供應商（包括您的大型主機供應商）的第三方風險管理。現代化在兩方面提供幫助。首先，知識圖譜本身即可作為 DORA 所要求的 ICT 資產清冊。它對映每一支程式、每一條資料流、每一項外部相依。監管機構可以直接查詢它。
其次，運行於雲端基礎設施上的遷移後元件，本質上更容易進行韌性測試。您可以隨需建置測試環境、執行混沌工程情境，並在不影響正式環境的情況下驗證復原程序。我們見過有機構在法規檢查中將知識圖譜作為證據，以證明他們了解自身的技術版圖——甚至在遷移尚未完成之前便如此。
本解決方案頁面背後的方法論，奠基於我們在舊有系統現代化與知識圖譜架構方面已發表的研究。
具儲存庫感知能力的知識圖譜與 GraphRAG，如何克服導致 AI 程式碼轉譯在企業 COBOL 系統上失敗的「迷失於中段（Lost in the Middle）」症候群。
對一家中型機構而言，第 1 年 20-30% 的 MIPS 縮減，通常每年可省下 50 萬至 200 萬美元。
知識圖譜評估需時 4-6 週。無論您是否繼續進行遷移，您都會獲得一份完整的程式碼庫相依地圖、一份死碼報告，以及一份抽取排序排名。評估本身就是一項永久資產。