COBOL 至今仍支撑着英国银行、保险公司、公共部门机构和大型零售商所运行的大量软件。其中很多程序处理的是资金，而且很多在如今维护它们的开发者加入这些机构之前很久就已经在运行了。随着 COBOL 专业人才逐渐退出劳动力市场，现代化的压力逐年增加，而 COBOL 到 C# 迁移正是英国企业最常考虑的路线之一。

对于已经深度投入微软技术栈的机构而言，运行在 .NET 上的 C# 是当前最强的迁移目标之一。它是一门现代、静态类型、面向对象的语言，可以在 .NET 8 及更高版本上跨平台运行，并且拥有一项使其特别适合 COBOL 的特性：一个专为精确金融运算而生的原生 decimal 类型。

本指南将说明一次 COBOL 到 C# 迁移到底涉及哪些工作、英国企业有哪些可选方法、成本如何，以及如何管理风险。

TL;DR

  • 对于已经采用 .NET 或 Azure 的机构，C# 是最契合的 COBOL 迁移目标，它原生的 128 位 decimal 类型无需第三方库即可直接映射 COBOL 的压缩十进制字段
  • 三种主要方法（自动化转换、并行重写和渐进式的“绞杀者（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 驱动。这类系统风险最高，因为事务边界、回滚行为和连接管理都需要谨慎地映射到 .NET 的对应机制上。

报表生成系统。 COBOL 报表通常被迁移到 C# 管道中，输出为现代格式：PDF、Excel 或 Web 仪表板。

接口与中间件层。 位于旧系统与数据库之间的 COBOL 程序，在现代化架构中往往会变成 C# 服务。

那些需要真正翻译的 COBOL 构造

一次安全的迁移取决于翻译 COBOL 的语义，而非逐行做文本替换。需要真正映射的构造包括：

  • PERFORM 范围 会变成 C# 方法调用，段落（paragraph）和节（section）被拆解为方法。
  • EVALUATE / WHEN 映射为 C# 的 switch 语句或模式匹配。
  • 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#。做得好，输出的是结构正确的 C# 12，带有命名空间、类和正确的 decimal 映射。做得草率，则会生成一个塞满静态方法的单一类，比原来的 COBOL 更难维护。

最适合： 优先目标是快速消除 COBOL 依赖、随后再进行渐进式重构的大型代码库。

风险： 没有任何工具能生成可直接投产的完整系统。嵌入式 SQL、CICS 交互和动态调用仍需人工决策。

Mecanik COBOL 到 C# 迁移工具 展示了优秀的自动化转换应有的样子。它运行的是一条完整的编译器流水线（词法分析器、解析器、语义分析器、代码生成器），而非文本替换；它将 COBOL 的节和段落拆解为 C# 方法，将 COMP-3 字段映射到原生 decimal，解析包括嵌套 copybook 在内的 COPY / REPLACE 指令，并生成一份 Migration Report，标记出每一处需要人工处理的 EXEC SQL、EXEC CICS 和动态 CALL。它还处理各种实际细节，例如为与 C# 保留字冲突的标识符加前缀，以及将 ACCOUNT-RECORD 风格的名称转换为 PascalCase。

2. 并行重写

C# 系统与现有 COBOL 系统并行搭建。二者针对相同的输入运行，输出彼此互相校验，直到 C# 系统通过验证，此时 COBOL 被停用退役。

最适合： 不容中断连续性的关键业务系统，例如支付、薪资和福利发放。

风险： 并行运行两套系统会在迁移期间使运营成本翻倍，并要求严格的对账。

3. 渐进式迁移（Strangler Fig）

一个接一个地将单个 COBOL 程序替换为 C# 等价物。系统先变成混合体，最终成为纯 C#。

最适合： 无法进行完整重写的大型单体 COBOL 系统。它让团队能够边学习边迭代，同时保持业务运转。

风险： 混合状态可能持续得比计划更久，并且要求在 COBOL 与 C# 组件之间进行谨慎的接口设计。

对于大多数英国企业的迁移而言，将绞杀者（strangler fig）方法与针对样板代码密集部分的选择性自动化转换相结合，能在风险与推进速度之间取得最佳平衡。

英国的 COBOL 到 C# 迁移成本

成本在很大程度上取决于代码库规模、复杂度和所采用的方法。英国企业项目的参考区间如下：

系统规模方法预估成本
小型（< 50,000 行）并行重写£80,000 至 £200,000
中型（50,000 至 500,000 行）Strangler Fig£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 迁移指南 则以与本文相同的深度介绍了最受欢迎的替代目标语言。

对于运行在 IBM z/OS 或类似基础设施上的 COBOL 迁移，Mecanik 遗留大型机迁移服务 在代码迁移之外，还涵盖基础设施退役。

关键风险及其管理方法

COBOL 到 C# 迁移超支或失败往往出于可预见的原因：

未记录的业务逻辑。 COBOL 系统往往承载着 30 到 40 年的业务规则，它们嵌入在代码中，却没有任何外部文档。发现并记录这些逻辑是任何迁移中最耗时、风险最集中的部分。

数据格式依赖。 压缩十进制（COMP-3）、EBCDIC 编码和定宽布局没有自动的 C# 等价物。C# 的 decimal 类型干净地解决了运算这一面，但在切换之前，每个字段仍需用真实数据进行映射和测试。

数据访问层。 转换 COBOL 逻辑往往比替换其数据访问更容易。针对 DB2 的 EXEC SQL 和 VSAM 文件处理必须重新设计到 ADO.NET、Entity Framework Core 或 Dapper 之上，这常常是单项工作量最大的部分。

性能预期。 一个通宵清理 1000 万条记录的 COBOL 批处理作业设定了一条标准，草率的 C# 重写未必能够达到。性能分析、优化，有时还包括架构上的调整，都是必需的。

回归测试覆盖率。 证明 C# 输出与 COBOL 一致的唯一可靠办法，是用真实数据（必要时匿名化）进行全面的回归测试。在迁移开始之前就构建这套测试是不可省略的。

切换风险。 在生产环境中切换到 C# 是风险最高的时刻。一份包含回滚流程和对账检查的详尽切换计划是必须的。

关键要点

  • 对于采用 .NET 或 Azure 技术栈的机构，C# 是最强的 COBOL 迁移目标，主要是因为它原生的 128 位 decimal 类型能以精确精度、无需外部库地直接映射 COBOL 的压缩十进制字段。
  • 三种主要方法是自动化转换、并行重写和渐进式迁移；大多数英国企业项目采用带有选择性自动化的绞杀者（strangler fig）方法。
  • 成本从小型系统约 £80,000 到完整大型机退役的数百万英镑级项目不等。
  • 最大的风险是未记录的业务逻辑、数据格式依赖，以及数据访问层的重新设计。在迁移开始前就着手解决这三者至关重要。

常见问题（FAQ）

为什么要从 COBOL 迁移到 C#，而不是 Java 或 Python？ 当你的机构运行在 .NET 生态系统或 Windows 与 Azure 基础设施之上时，选择 C#。它原生的 decimal 类型尤其契合 COBOL 的金融字段。Java 是采用 JVM 团队的自然选择，而 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# 迁移需要多长时间？ 小型、文档齐全的系统需要三到九个月。中型企业系统需要十二到二十四个月。大型大型机项目要完成完整退役可能需要三到五年。