每一次大型机迁移，都从有人去搜索大型机迁移工具开始，而随后那场厂商演示看起来总是格外可信。几千行 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# 中没有干净的等价物，所以产出照搬了原来的结构。要得到可维护的代码，必须在转换之后由人来重构。

大型机迁移工具会漏掉哪些数据问题？ 它们把格式转换处理得很好，却解决不了含义。被挪作他用的填充字段、带世纪推断规则的六位日期、只在程序内部定义的状态码，以及被容忍的重复键，都需要人来判断，才能正确设计目标模式。

怎样验证迁移后的系统行为完全一致？ 在约定的时间段内用同一批生产输入同时跑两套系统，逐字段比对输出，并为每个迁移过来的数据集提供记录条数和控制总额作为支撑。请把这套比对装置当作一项独立交付物来构建，因为差异是持续被发现的，而不是一次性全部暴露。