Bridgestone 評估超過 120 萬行 z/OS COBOL 與 JCL，遷移時仍由人員監督關鍵業務邏輯與合規事項。AWS 個案顯示，大型主機轉型牽涉的不只程式碼，還有資料庫、測試與系統整合。AI 能否降低盤點和改寫成本，仍要看轉換後的業務行為能否驗收、出錯時能否回復。

這個問題要先定義清楚。COBOL 現代化可能是整理文件、重構、轉換語言或更換平台，各自的風險與驗收條件不同。評估 AI 參與哪一步時，可參考生成式 AI 導入的人工覆核與流程驗收，不要只看程式碼能否生成。

一、AI 協助 COBOL 遷移，先從理解舊系統開始

優先用 AI 協助程式盤點、依賴整理和文件補足，再由熟悉業務的人員確認。這些產出可縮短理解程式的起步時間，仍不能代替遷移決策或行為驗收。

Anthropic 說明 Claude Code 可追蹤程式入口、呼叫、資料流與模組關係，並建議逐一處理元件。這是廠商對產品能力的描述。實際盤點應要求呼叫圖、資料欄位用途和批次流程都能連回程式位置，方便工程師覆核。

IBM Research 將靜態程式分析與大型語言模型結合，評估 20 個 GenAPP 程式及 10 個客戶應用程式；報告的中位數結構品質分數逾 80%，功能分數高於 75%。這是特定樣本與評分方法的結果，不能代表其他程式庫。它顯示轉換工具需要程式結構等上下文，輸出也須逐項測試。

遷移試點也可參考AI 工具評估如何定義測試任務與判準：檢查工具能否找出指定依賴、標註來源，並在不同版本中產生可覆核結果。

二、遷移難點藏在程式碼周邊的依賴

因為系統行為還受執行平台、資料格式、排程和外部介面影響。只搬動程式語言，可能留下未處理的資料語意、交易特性與營運流程。

IBM 軟體主管 Rob Thomas 指出，程式翻譯與平台現代化是不同工作。批次順序、失敗後重跑方式、交易提交、欄位編碼與金額精度，都可能藏在程式外的設定或慣例中。

AWS 文件列出的主機元件還包括 JCL、CICS、BMS、Db2 與 VSAM（虛擬儲存存取法，一種資料集存取方式）。盤點應涵蓋排程、交易介面、資料來源及下游系統，並確認新環境支援原有行為、切換後有人監控維護；無人能說明的依賴須列為待查，不能讓 AI 猜補。

Bridgestone 使用 AWS Transform 分析並重整超過 120 萬行 z/OS COBOL 與 JCL，轉換 Db2 和 VSAM 資料庫，再以測試確認整合運作；人員仍監督關鍵邏輯與合規。這是 AWS 客戶案例，未公布可重現的完整測試基準，不能據此推估其他企業所需時間。

「If used irresponsibly or unchecked, AI can help you drive off a cliff faster.」（Bridgestone 技術主管，AWS 個案訪談）

三、AI 轉換結果要怎麼證明行為一致

以相同輸入並行執行新舊程式，逐筆比較輸出、例外處理和交易結果。測試資料要涵蓋日常路徑與少見邊界，並由業務負責人核准差異是否可接受。

程式能編譯，不代表行為等價。帳務測試須涵蓋金額精度、負數、跨月日期、空白欄位、重複交易與逾時重試。從作業記錄整理代表性輸入和例外案例，並寫明預期輸出、容許差異及核定者，避免只測正常路徑。

Itaú Unibanco 先用 AWS Transform 分析 COBOL、IMS、CICS 與 Db2，再以 Kiro 轉換部分應用。AWS 稱，盤點時間由三個月縮至兩週、測試案例建立時間減少約 97%，特定應用遷移時間減少約 75%。這是廠商公布的單一客戶結果，不能外推；其流程先整理規則、建立驗證框架，再讓程式通過 CI/CD（持續整合與持續交付）流程。

每個轉換單元都要有版本、備份和切回步驟。並行期間須避免重複寫入，或先定義同步與衝突處理方式。若差異超標，就停止擴大、修正後重跑測試。

相同測試資料分別輸入 COBOL 與 Java 程式，再由比對關卡標出一致結果與差異。
只有用相同輸入逐項比對新舊輸出，才能找出語法轉換後仍未保留的業務行為。

四、試點要比較哪些轉型路徑與整合成本

依問題選擇原地重構、分段替換或整體改寫，並把人工覆核、整合、測試與維運算入總成本。若目標只是改善維護性，未必要先搬離主機或全面換語言。

原地重構保留執行環境，先整理程式、文件與測試；分段替換以介面隔離舊模組，再逐步換掉邊界清楚的流程；整體改寫則須先掌握業務規則、資料遷移與切換安排。先確認問題是人才、變更速度、平台費用或資料整合。問題如果沒定義對，後面的方法就會錯。

比較三條路徑時，統一計入盤點、覆核、測試資料、介面調整、平行運作、切換、回復演練及後續維護工時，並記錄原本耗時，才能判斷總投入是否下降。缺少測試基準或規則確認者時，應先補齊條件。

「Translating code is one thing. Modernizing a platform is something else entirely.」（Rob Thomas，IBM Software 資深副總裁）

五、用一份驗收清單判斷是否擴大遷移

範圍、基準、責任人、測試門檻和回復方式都明確，且新舊結果符合業務核准條件後，才評估擴大。一次只增加已理解的流程，保留停止與切回的選項。

啟動試點前，先用以下五項檢查是否具備可驗收條件：

  1. 選定邊界清楚的流程：例如一項批次報表或單一計算模組，列出輸入、輸出、上下游介面與排程，不先挑依賴最複雜的核心交易。
  2. 建立舊系統基準：留存代表性資料、例外案例、輸出結果、效能需求及目前的人工處理工時，並確認資料使用權限。
  3. 標記每項 AI 產出：程式摘要、規則推論、程式碼變更和測試案例都要連回來源，交由指定工程師或業務負責人確認。
  4. 預先設定通過與停止條件：定義輸出差異、效能、錯誤率、整合測試和安全檢查的門檻；任一關鍵業務結果不一致，就停下來查原因。
  5. 演練切換與回復：安排新舊系統並行、資料同步、監控告警和切回操作，估算總工時後再決定是否擴大。
五個相連步驟依序呈現界定流程範圍、留存舊系統基準、覆核轉換內容、設定通過門檻與演練回復。
範圍、基準、責任、門檻與回復方式都確認後，試點結果才足以支持是否擴大。

試點結果只適用於受測程式、資料與環境。未涵蓋尖峰批次、例外分支或下游介接，就不能視為整體上線證明。擴大前確認規則、差異、回復能力與含維護成本的效益。

  • AI 可協助 COBOL 程式盤點、依賴整理與轉換候選產生，產出仍須有來源可查並經人工確認。
  • 語言轉換只是遷移的一部分，排程、資料、介面、交易與維運也要納入驗收。
  • 以新舊並行比對、例外測試、停止條件和回復演練決定是否擴大，不以程式生成速度代替成效評估。

常見問題

Q1：AI 可以直接把 COBOL 改成 Java 嗎？

AI 工具可產生轉換候選或協助重構，但轉換結果仍須經編譯、測試、程式覆核與業務規則確認，不能只憑語法正確就上線。

Q2：COBOL 遷移試點應先挑哪種程式？

可先挑輸入輸出清楚、依賴較少、能與現行流程並行的模組，並確認它有足夠代表性資料可測試。核心交易或邊界不明的程式應先完成盤點。

Q3：試點省下的時間可以直接當成遷移效益嗎？

不宜。還要計入人工覆核、測試、介接、切換和後續維護；若公開案例沒有說明基準與方法，其數字只能視為該案例的廠商資料。

Q4：什麼情況應該暫停擴大？

若新舊系統的重要輸出無法解釋差異、關鍵依賴尚未確認、測試覆蓋不足，或切回程序沒有演練，就先停在試點範圍內處理。