每一次大型主機遷移，都從有人去搜尋大型主機遷移工具開始，而隨後那場廠商展示看起來總是格外可信。幾千行 COBOL 送進去，可讀的 Java 出來，測試套件全部通過，簡報承諾七成到八成的自動化。展示本身通常是誠實的，只是它跑的那份程式碼，行為跟你的程式碼毫無相似之處。

本文梳理真實存在的工具類別，說明每一類真正擅長什麼，以及在真實負載下各自最容易垮掉的具體位置。它寫給必須在立案報告上簽字的人，而不是寫給組織內部替廠商說話的人。

實話實說： 大型主機遷移工具確實做了大量有用的工作，尤其是在分析、資料搬運與機械轉換這三件事上。它們做不到的是理解你的業務規則。自動轉換可以穩定地產出能執行的程式碼，但產不出你的團隊願意維護的程式碼，而彌合這段落差，正是預算真正花掉的地方。

大型主機遷移工具的四個類別

按產品實際做什麼來歸類之前，這個市場看著擁擠不堪。幾乎所有產品都落進四類裡的一類，而一個真正的遷移專案至少會從其中三類中取用工具。

探勘與分析工具讀取你的原始碼資產，告訴你手上到底有什麼。它們剖析 COBOL、JCL、副本簿與資料庫定義，接著建立呼叫圖、資料血緣圖與相依樹。這一類最不起眼，卻最穩定地創造價值，因為對一套累積了四十年的系統，組織裡沒有任何一個人握有完整圖像。

重新託管與模擬平台讓編譯好的大型主機工作負載跑在通用硬體或雲端主機上。你的 COBOL 還是 COBOL，JCL 還是 JCL，由一層相容層來提供過去由大型主機負責的執行期服務。

自動轉換工具把原始碼從 COBOL 轉成 Java、C# 或另一種現代目標語言。這是買方最興奮的一類，也是最常令人失望的一類，原因見下文。

資料遷移工具搬運資料本身：把 VSAM 檔案、循序資料集與 DB2 資料表遷往關聯式或雲端原生儲存。它們能處理字元集轉換、壓縮十進位欄位，以及通用 ETL 產品根本剖析不了的紀錄版面配置。

主要雲端業者各自把其中幾類打包在一起提供，而專業廠商這些年透過併購已經大幅整合。在簽下多年期支援合約之前，先查清楚這個產品現在歸誰所有、藍圖上給出了什麼承諾，因為在這個市場裡，所有權變動比技術變動還頻繁。

分析工具真正做對了什麼

如果只買一類，就買這一類。探勘工具能回答的問題，若靠人力手工去答，需要一支外包團隊做上好幾個月。

好的分析產品會告訴你：正式環境裡真正被呼叫的是哪些程式，哪些已經死了十年；資料如何從一個畫面欄位流經五六支程式，最後落進一張 DB2 資料表；哪些副本簿被多個子系統共用；以及真正危險的程式碼住在哪裡。改變計畫的正是最後這項輸出。每一套大型主機資產裡都有那麼一小撮程式，其他所有東西都依賴它們，而它們很少是業務方以為的那幾支。

侷限在於解讀。一張有四萬個節點的相依圖是資料，不是洞見。仍然需要有人盯著這份輸出，把它歸攏成業務能力，再決定什麼先動。那些承諾自動推導業務規則的工具，產出的東西更接近把程式碼換個說法，而不是對意圖的描述，而兩者恰好在程式碼含有缺陷、業務方早已默默適應的那個位置上分道揚鑣。

在確定路線之前先跑分析。我們關於大型主機現代化策略 的指南講了這些發現應當如何影響重寫、重構還是換平台的決定。

重新託管平台：快、真實，但不是現代化

重新託管是所有選項裡結果最可預測的一個，也正因為如此長期被低估。

它的主張很直白。你的 COBOL 在一個模擬大型主機執行期服務的平台上被重新編譯或直譯執行，於是交易處理、批次排程、檔案處理與工作控制的行為一如從前。因為原始碼幾乎不變，測試負擔遠低於其他任何路線，專案以月為單位收尾，而不是以年計。

節省是真實的，它來自硬體與授權模式，而不是來自軟體。不少組織在離開實體大型主機之後回報年度營運成本大幅下降，這筆錢往往足以支撐下一階段的工作。

重新託管做不到的，恰恰是多數董事會核准這類專案的那個理由。託管成功之後，你手裡仍然是一套 COBOL 程式碼庫，仍然需要 COBOL 開發者，找到人的難度一點沒變。應用本身也沒有變得更容易改動。重新託管為你買來時間與現金，這確實有價值，但應當誠實地稱它為平台變更，而不是現代化。

它還引入了一項新的相依。你把 IBM 的執行環境換成了某家廠商的相容層，你的正式環境從此依賴這家廠商繼續提供支援。考量到這個市場整併的頻率，這是一項值得寫進立案報告的風險。

自動轉換：真正的麻煩住在這裡

COBOL 自動轉換是能跑的，這不是問題。問題是產出長什麼樣，以及跟它共處要付多少代價。

轉換引擎大體上是忠實的。它們保留行為，包括沒有任何人想要的那些行為，因為忠實是唯一站得住腳的設計目標。工具無從知道保費計算裡某個進位捨去的怪癖，其實是精算師們從 1997 年起一直在人工補償的缺陷，於是它把它一模一樣地重現出來。這是正確的選擇，同時也意味著你的新 Java 系統繼承了舊系統累積下來的每一處古怪。

產出同樣受輸入形狀的束縛。用 GOTO 鏈、PERFORM THRU 的順延、ALTER 敘述，以及可以從好幾個方向進入的段落寫成的 COBOL，分解不出乾淨的方法，因為根本不存在一種乾淨的分解。冒出來的是照著 COBOL 控制流程走、沿用 COBOL 變數名稱、往往比原件更難讀的 Java 或 C#。業界把它叫作 JOBOL，而完全可能出現的局面是：遷移順利完成，留下一套兩種語言裡都沒人維護得了的程式碼庫。

有幾種結構造成的痛苦格外不成比例，值得盡早排查，因為它們決定手工工作量的估算。

決定手工工作量的五種結構

第一是壓縮十進位運算。COBOL 的 COMP-3 欄位與定點十進位語意無法對應到浮點數，任何允許這樣對應的工具，都會算出在小數點後第四位與大型主機不一致的財務結果。正確的轉換使用任意精度十進位型別，它更慢，而且必須在每一條計算路徑上一致地套用。

第二是字元編碼。EBCDIC 到 ASCII 的轉換是機械的，但排序規則並不相同，因此任何依賴排序次序的東西都可能改變。報表以另一種順序出來，範圍判斷的行為不一樣，鍵值比較給出的結果在新系統裡是對的，對照舊系統卻是錯的。

第三是 REDEFINES 與可變紀錄。同一塊儲存區被按幾種不同方式解讀，在強型別語言裡沒有天然的對應物。產生的程式碼往往是包在存取子裡的位元組陣列操作，能跑，維護起來極其難受。

第四是交易語意。CICS 的偽對話式程式設計，也就是在畫面互動之間用通訊區攜帶狀態的做法，與任何現代 Web 或服務模式都對不上。模擬它會做出奇怪的東西；把它認真重新設計，那就是重寫展示層。

第五是組合語言常式，也是最穩定地被低估的一項。幾乎每一套長壽資產裡都藏著幾個組合語言模組，通常出自多年前就退休的某個人之手，做著某件效能關鍵或與平台綁定的事。沒有工具能轉換它們。它們由人依據行為、在測試保護下手工重寫。

如果你正在權衡目標語言，我們關於 COBOL 遷移到 Java 與 COBOL 遷移到 C# 的詳細指南講了這些結構在各自生態裡如何落地。

資料遷移工具與那些會咬人的細節

資料搬運得到的關注比程式碼轉換少，造成的延誤至少一樣多。

專業工具在這裡配得上它的位置，因為大型主機的資料格式確實彆扭。它們理解副本簿版面配置、壓縮十進位與區間十進位欄位、符號疊打、OCCURS DEPENDING ON 子句，以及一個 VSAM 檔案裡可能混著好幾種紀錄型態、靠第十二個位元組上的一個字元加以區分這件事。通用 ETL 產品不理解，硬要用它們的團隊，通常最後自己重造了一個更差的同類能力。

更難的問題是語意而非技術。大型主機檔案常常以關聯式綱要無法直接表達的方式承載含意：被挪作他用的填充欄位、以六位整數儲存並配一條推斷世紀規則的日期、有效取值只寫在某支程式裡而不在對照表中的狀態旗標，以及應用一直容忍的重複鍵。決定這些東西在目標綱要裡該變成什麼，是分析工作，無法自動化，因為答案只存在於人的腦子裡。

一開始就把對帳排進計畫。每一個遷移過來的資料集都需要紀錄筆數、控制總額與欄位層級比對，而且要反覆跑，不是跑一次。多數專案還需要一段雙軌執行期：兩套系統處理同樣的輸入，輸出逐位元組比對，直到差異被消除或被解釋清楚。那套比對裝置是一件有自己開發成本的真正軟體，它屬於計畫，不屬於預備金。

如何選擇不會後悔的大型主機遷移工具

有幾條原則能讓這類決定踩在地上。

堅持用你自己最爛的程式碼做概念驗證，而不是用廠商的範例。挑那個人人繞道的模組，就是帶著組合語言呼叫與七層 REDEFINES 的那個，請他們轉換它。這個結果比任何客戶案例都更能說明問題。

具體地問這個工具如何處理十進位運算與排序次序，並要求看產生出來的程式碼本身，而不是一份摘要。如果廠商無法從醜陋的輸入裡拿出可讀的程式碼，那就假定人工修補的估算比報價更大。

把自動化百分比當作行數的度量，而不是工時的度量。一個能轉換九成敘述的工具，仍可能把裝著全部風險的那一成留給你，而那一成經常吃掉一半以上的時程。

最後，為任何工具都不碰的部分留出預算：測試裝置、對帳、平行執行、維運手冊與再訓練。我們的 COBOL 遷移成本與時程指南 說明了這些科目在一個專案中通常如何分布。

在做決定之前，先拿一份獨立判斷

Mecanik 以工程師而非工具經銷商的身分參與舊有大型主機遷移 與 COBOL 遷移 專案，這意味著你選哪個平台，我們都拿不到佣金。我們跑探勘流程，把一個真正難啃的模組分別用人工與用工具各轉一遍，在任何人簽字之前，把差別擺給你看。

如果你的資產規模更小，或者你的問題更多關於目標語言而非工具，我們的 COBOL 現代化服務 頁面說明了我們如何界定這類工作的範圍。無論哪種情況，有用的第一步都是就你的程式碼庫裡究竟有什麼做一次簡短的交談，因為工具這個問題的答案完全取決於它。

相關文章: COBOL 現代化服務：如何挑選供應商 、COBOL遷移至Python - 英國企業指南2026 、COBOL 遷移至 Go：英國企業指南 、COBOL 遷移到 Rust - 英國企業指南 。

常見問題

大型主機遷移工具能把整個專案自動化嗎？ 不能。自動轉換通常能轉掉絕大多數敘述，但剩下的部分包含組合語言模組、交易狀態處理、可變紀錄結構與未被記錄的業務規則，這些都需要人工完成。測試、對帳與平行執行同樣不會因為程式碼自動化程度更高而減少。

重新託管與自動程式碼轉換哪個更好？ 它們解決的是不同的問題。重新託管能快速把工作負載搬離大型主機硬體並降低營運成本，但你手上仍然是 COBOL。程式碼轉換改變的是語言與人才市場，代價是成本與風險都高得多。很多組織先做重新託管，再用省下來的錢資助分階段的轉換。

轉換出來的 COBOL 程式碼為什麼這麼難讀？ 因為轉換引擎會忠實保留行為，連同 COBOL 的控制流程、命名與資料結構一起保留。圍繞 GOTO 鏈與共用儲存區建構的程式碼在 Java 或 C# 中沒有乾淨的等價物，所以產出照搬了原來的結構。要得到可維護的程式碼，必須在轉換之後由人來重構。

大型主機遷移工具會漏掉哪些資料問題？ 它們把格式轉換處理得很好，卻解決不了含意。被挪作他用的填充欄位、帶世紀推斷規則的六位日期、只在程式內部定義的狀態碼，以及被容忍的重複鍵，都需要人來判斷，才能正確設計目標綱要。

怎樣驗證遷移後的系統行為完全一致？ 在約定的時間區間內用同一批正式輸入同時跑兩套系統，逐欄位比對輸出，並為每個遷移過來的資料集提供紀錄筆數與控制總額作為佐證。請把這套比對裝置當作一項獨立交付物來建構，因為差異是持續被發現的，而不是一次性全部暴露。