COBOL 至今仍是英國銀行、保險公司、公部門機構與大型零售商所運行軟體的重要基石。這些系統大多負責處理金錢，而且許多早在今日負責維護它們的開發人員加入組織之前就已經在運行。隨著 COBOL 專業人才逐漸退出職場，現代化的壓力年年升高，而 COBOL 到 C# 遷移正是英國組織最常考慮的路徑之一。

對於已經深耕 Microsoft 技術堆疊的組織而言，運行於 .NET 上的 C# 是目前最強的遷移目標之一。它是一種現代、靜態型別、物件導向的語言，可跨平台在 .NET 8 及更高版本上運行，並且具備一項讓它特別適合 COBOL 的特性：專為精確金融運算而打造的原生 decimal 型別。

本指南說明 COBOL 到 C# 遷移實際上牽涉哪些工作、英國企業可採用的方法、成本，以及如何管理風險。

TL;DR

  • 對於已採用 .NET 或 Azure 的組織而言，C# 是最契合的 COBOL 遷移目標，其原生的 128 位元 decimal 型別無需第三方函式庫，即可直接對應 COBOL 的封裝十進位（packed-decimal）欄位
  • 三種主要方法（自動化轉換、平行重寫，以及漸進式「絞殺榕」（strangler fig）遷移）各有不同的風險與成本樣貌；多數英國企業採用混合策略
  • 一個中型遷移通常需要 £200,000 到 £800,000，並歷時一到兩年；低估範圍是最常見的失敗原因
  • 自動化轉換工具能產生結構正確的 C#，但並非完成的系統；無論使用何種工具，資料存取層、測試與業務驗證仍是需要人力的工作

為何 C# 是 COBOL 遷移的強力目標

C# 並不是 COBOL 唯一合理的目的地。Python、Java、Go、C++ 與 Rust 依情境不同都是可行的選擇。C# 之所以脫穎而出，有幾項具體原因：

原生 decimal 精度。 這是支持 C# 最強而有力的技術論點。COBOL 的金融欄位使用封裝十進位（COMP-3）與數值型 PIC 9 子句來表示精確的十進位值。C# 內建的 decimal 型別是一種 128 位元、固定精度、以 10 為基底的型別，專為金融與貨幣計算而設計。COBOL 的十進位欄位可直接對應到它，在無捨入意外、無需外部函式庫的情況下保留精確運算。Java 可以用 BigDecimal 達到相同的正確性，但只能透過較為冗長的物件 API；而仰賴二進位浮點數的語言（Java 中的 double、Go 中的 float64、Rust 中的 f64）若不額外投入工作，並不適合處理金額。

.NET 生態系。 許多英國企業已經運行 Windows Server、SQL Server、Active Directory 與 Azure。對這些組織而言，將 COBOL 遷移到 C# 能讓現代化後的系統留在其團隊本來就在營運、監控與防護的技術堆疊之內。資料存取可以乾淨地對應到 ADO.NET、Entity Framework Core 或 Dapper。

跨平台的現代執行環境。 現代的 .NET 已不再侷限於 Windows。C# 12 的程式碼可在 .NET 8 或更高版本 （一個長期支援版本）上編譯並運行於 Windows、Linux 與 macOS，並可自然地以容器形式部署到 Azure、AWS 或 GCP。遷移到 C# 不再會把您綁死在單一作業系統上。

靜態型別與工具鏈。 C# 強大的靜態型別能在編譯期攔截整類錯誤，這在轉譯數十年歷史的業務邏輯時尤為重要。Visual Studio、Rider 與 .NET CLI 提供成熟的除錯、效能剖析與重構支援。

開發人員供給。 C# 在英國一直是最廣泛使用的企業語言之一，因此長期招募與維護的人才池相當充裕。

認清您要從什麼遷移

在英國企業情境中，COBOL 系統通常可歸為幾類，而遷移的性質會隨每一類而改變：

批次處理系統。 典型的 COBOL 工作負載：從檔案讀取大量記錄、循序處理，再寫回去。這類系統通常最容易遷移，並能良好對應到 C# 背景服務與串流 I/O。

交易處理系統。 線上交易處理，常由 IBM 大型主機上的 CICS 或 IMS 驅動。這類系統風險最高，因為交易邊界、回復（rollback）行為與連線管理全都需要仔細對應到 .NET 的對等機制。

報表產生系統。 COBOL 的報表功能通常會遷移到 C# 管線，輸出現代格式：PDF、Excel 或網頁儀表板。

介面與中介軟體層。 位於舊系統與資料庫之間的 COBOL 程式，在現代化後的架構中往往會變成 C# 服務。

真正需要轉譯的 COBOL 結構

安全的遷移取決於轉譯 COBOL 的語意，而非逐行做文字替換。需要真正對應的結構包括：

  • PERFORM 範圍 會變成 C# 的方法呼叫，段落（paragraph）與節（section）會分解為方法。
  • EVALUATE / WHEN 對應到 C# 的 switch 陳述式或模式比對（pattern matching）。
  • 88-level 條件名稱 會變成布林屬性或輔助方法。
  • MOVE CORRESPONDING、REDEFINES 與 OCCURS 需要仔細對應到型別化欄位、意圖的聯集，以及陣列或集合。
  • PIC 子句 對應到適當的 C# 型別：string 用於英數字元、short / int / long 用於有大小的整數，而 decimal 用於保留精度的封裝十進位欄位。
  • COPY 與 REPLACE 指令（copybook）必須在剖析之前或期間解析，包含巢狀的 copybook。
  • EXEC SQL（DB2）、EXEC CICS 與 VSAM 檔案存取 沒有可直接替換的 C# 對等物，是最可能需要刻意重新設計到 ADO.NET / Entity Framework Core 與現代服務模式的部分。
  • EBCDIC 編碼與固定寬度的記錄配置 需要明確轉換為 Unicode 與型別化模型。

遷移方法

主要有三種方法，各有不同的風險與成本樣貌。

1. 自動化轉換

工具會剖析 COBOL 並產生對等的 C#。做得好時，輸出是結構正確、具有命名空間、類別與正確 decimal 對應的 C# 12。做得草率時，會產出一個塞滿靜態方法的單一類別，比原本的 COBOL 更難維護。

最適合： 大型程式碼庫，其首要目標是快速消除對 COBOL 的依賴，之後再進行漸進式重構。

風險： 沒有任何工具能產出完成、可直接上線的系統。內嵌的 SQL、CICS 互動與動態呼叫仍需要人為決策。

Mecanik COBOL 到 C# 遷移工具 展示了優良的自動化轉換應有的樣貌。它運行一套完整的編譯器管線（語彙分析器、剖析器、語意分析器、程式碼產生器），而非文字替換，將 COBOL 的節與段落分解為 C# 方法，把 COMP-3 欄位對應到原生 decimal，解析 COPY / REPLACE 指令（含巢狀 copybook），並產生一份 Migration Report，標示出每一處需要人工處理的 EXEC SQL、EXEC CICS 與動態 CALL。它也會處理實務細節，例如為與 C# 保留字衝突的識別字加上前綴，以及把 ACCOUNT-RECORD 之類的名稱轉換為 PascalCase。

2. 平行重寫

C# 系統與既有的 COBOL 系統並肩建置。兩者針對相同的輸入運行，輸出彼此相互驗證，直到 C# 系統通過為止，屆時才將 COBOL 除役。

最適合： 不能冒中斷風險的關鍵任務系統，例如支付、薪資與福利給付。

風險： 在遷移期間平行運行兩套系統會使營運成本加倍，並要求有紀律的對帳。

3. 漸進式遷移（絞殺榕）

各個 COBOL 程式逐一被 C# 對等物取代。系統會先變成混合狀態，最終成為純 C#。

最適合： 全面重寫並不切實際的大型單體 COBOL 系統。它讓團隊能在維持業務運作的同時學習與迭代。

風險： 混合狀態可能比計劃持續得更久，並且需要在 COBOL 與 C# 元件之間精心設計介面。

對於多數英國企業的遷移而言，絞殺榕方法搭配對樣板程式碼密集區段的選擇性自動化轉換，能在風險與速度之間取得最佳平衡。

英國的 COBOL 到 C# 遷移成本

成本高度取決於程式碼庫的規模、複雜度與所採用的方法。英國企業專案的參考範圍如下：

系統規模方法估計成本
小型（< 50,000 行）平行重寫£80,000 到 £200,000
中型（50,000 到 500,000 行）絞殺榕£200,000 到 £800,000
大型（500,000+ 行）自動化 + 漸進式重構£500,000 到 £2,000,000+
舊式大型主機除役完整計劃£1,000,000 到 £10,000,000+

這些數字涵蓋分析、遷移、測試與上線支援。它們不包含持續的營運成本、訓練，以及常在專案中途浮現的下游整合工作。

Mecanik COBOL 到 C# 遷移服務 專精於英國企業遷移，涵蓋評估、轉換、Entity Framework 資料存取層實作，以及輸出一致性測試。對於正在權衡多種目標語言的組織，COBOL 遷移總覽 列出完整的選項範圍，包含 Python、Java、Go、C++ 與 Rust，而 COBOL 到 Python 遷移指南 則以與本文相同的深度探討最熱門的替代目標。

對於 COBOL 運行於 IBM z/OS 或類似基礎架構上的遷移，Mecanik 舊式大型主機遷移服務 會在程式碼遷移之外，一併涵蓋基礎架構的除役。

主要風險與管理之道

COBOL 到 C# 遷移超支或失敗，往往出於可預見的原因：

未記錄的業務邏輯。 COBOL 系統常承載 30 到 40 年、嵌入在程式碼中且沒有任何外部文件的業務規則。發掘並記錄這些邏輯，是任何遷移中最耗時、風險最高的部分。

資料格式相依性。 封裝十進位（COMP-3）、EBCDIC 編碼與固定寬度配置都沒有自動的 C# 對等物。C# 的 decimal 型別乾淨地解決了運算面，但每個欄位在切換前仍需以真實資料進行對應與測試。

資料存取層。 轉換 COBOL 邏輯往往比替換其資料存取更容易。針對 DB2 的 EXEC SQL 與 VSAM 檔案處理必須重新設計到 ADO.NET、Entity Framework Core 或 Dapper 上，而這常常是最大的單一工作項目。

效能預期。 一個能在一夜之間處理 1,000 萬筆記錄的 COBOL 批次作業，設下了一道天真的 C# 重寫可能達不到的標準。效能剖析、最佳化，有時甚至架構上的變更都是必要的。

回歸測試覆蓋率。 要證明 C# 的輸出與 COBOL 相符，唯一可靠的方式是以真實資料（必要時去識別化）進行全面的回歸測試。在遷移開始前就建立好那套測試套件並非可有可無。

切換風險。 在正式環境切換到 C# 是風險最高的時刻。一份含有回復程序與對帳檢查的詳盡切換計劃是不可或缺的。

重點摘要

  • 對於採用 .NET 或 Azure 技術堆疊的組織而言，C# 是最強的 COBOL 遷移目標，主要是因為其原生的 128 位元 decimal 型別無需外部函式庫，即可直接、以精確精度對應 COBOL 的封裝十進位欄位。
  • 三種主要方法為自動化轉換、平行重寫與漸進式遷移；多數英國企業專案採用絞殺榕方法搭配選擇性的自動化。
  • 成本從小型系統約 £80,000 到完整大型主機除役的數百萬英鎊計劃不等。
  • 最大的風險是未記錄的業務邏輯、資料格式相依性，以及資料存取層的重新設計。在遷移開始前就處理好這三者至關重要。

常見問題（FAQ）

為什麼要從 COBOL 遷移到 C# 而不是 Java 或 Python？ 當您的組織運行於 .NET 生態系，或 Windows 與 Azure 基礎架構之上時，就選擇 C#。它原生的 decimal 型別特別契合 COBOL 的金融欄位。對於在 JVM 上的團隊，Java 是自然的選擇，而 Python 則適合著重可讀性與 AI 整合的組織。

是什麼讓 C# 的 decimal 型別更適合 COBOL 遷移？ C# 的 decimal 是一種 128 位元、以 10 為基底、固定精度、專為金融計算而打造的型別，因此 COBOL 的 COMP-3 與 PIC 9 十進位欄位能直接對應到它，具備精確運算且無需第三方函式庫。使用二進位浮點數表示數值的語言，需要額外投入才能符合 COBOL 的十進位行為。

遷移後的 C# 程式碼是在 Linux 上運行，還是只能在 Windows 上？ 兩者皆可。C# 12 以 .NET 8 或更高版本為目標，可跨平台運行於 Windows、Linux 與 macOS，並能以標準應用程式或容器形式部署到 Azure、AWS 或 GCP。

COBOL 邏輯可以自動轉換成 C# 嗎？ 可以，需要搭配工具。一個好的轉換器會產出結構正確、具備適當類別結構與 decimal 對應的 C#，但會把內嵌的 SQL、CICS 互動與動態呼叫標示出來交由人工處理，而不是自行猜測。資料存取層與業務驗證仍是人力任務。

COMP-3 與 EBCDIC 這類 COBOL 資料格式會怎麼處理？ COMP-3 欄位能乾淨地對應到 C# 的 decimal。EBCDIC 文字與固定寬度配置則需要明確轉換為 Unicode 與型別化模型，而且每個結構在正式使用前都應以真實資料測試。

一次 COBOL 到 C# 遷移需要多久？ 小型且文件完善的系統需要三到九個月。中型企業系統需十二到二十四個月。大型大型主機計劃若要完整除役，可能需要三到五年。