另一位开发者 walnut close 现身评论道：
我在企业平台迁移方面有 30 年的经验，既从系统供应商的角度参与过，也曾作为企业 IT 架构师和高管负责相关工作。我可以毫不夸张地说，从服务交付、一致性、安全性和业务连续性的角度来看，这次迁移注定会失败。
系统和编程语言的选择确实重要，但它们本身并不是决定成败的关键，甚至通常都不是最主要的因素。架构设计、项目管理、测试、范围和质量控制、过渡与上线规划……这些才是影响成败的核心。而现在这些家伙谈论的那些技术问题，远远没有这些因素重要。选错技术确实会毁掉一个项目，但光是选对技术，绝对无法保证项目成功。
还有--这一点我必须强调--即使他们在技术、架构和项目管理上做得滴水不漏，也不会因此减少欺诈和错误，除非他们真正理解欺诈和错误的来源，并在项目需求中明确设计出检测和纠正机制。COBOL 既不是欺诈的根源，也不会天然导致系统性错误。而 DOGE 至今没有拿出任何有说服力的欺诈证据，甚至连系统性错误的实际问题都几乎没找到，所以在这方面，他们注定也要失败。
这让我想起过去那些由大型咨询公司主导的企业级系统迁移灾难--只是这次的规模被无限放大了。唯一的区别是，这次涉及的金额高达数万亿美元，影响范围遍及整个国家，而负责这个项目的"专家"对他们要替换的系统几乎一无所知，这种错配的程度，比以往任何一次大型企业咨询灾难都要严重几个数量级。
不仅如此，开发者 Lemon640 此前在深入研究 COBOL 后尝试升级自家的旧项目，但现实却给了他当头一棒。他直言："我遇到了难以逾越的障碍。" 以下是他列举的一些严重问题：
1. 真实 COBOL 代码的复杂性远超预期
Lemon640 称，自己最初接触的 COBOL 代码仅限于入门级教材中的"玩具"版本，而实际应用中的 COBOL 代码与任何标准（包括 1985/2002 版本）都存在巨大差异。这些差异并非源于对新标准的遵循或现代编程实践的引入，而是由于长期积累的各种自定义扩展。统一不同版本的 COBOL 代码到一个通用转换目标语言，几乎是不可能完成的任务，尤其是当关键字、语法结构（如 PICTURE 句法）被广泛修改，甚至引入了全新的关键字和数据类型时。
2. COBOL 生态系统鼓励通过修改语言本身来扩展功能
与现代编程语言主要依赖库或模块来扩展能力不同，COBOL 生态更倾向于直接修改语言，引入新的动词或 PICTURE 类型。这种做法导致在构建兼容的目标语言时，必须考虑如何处理大量的自定义扩展，而相比之下，现代语言通常通过库、函数和内置数据类型实现类似功能，以确保更好的可维护性。
