Oracle Forms迁移，AI别急着抢功

这篇文章最有价值的信息是，有人用两周把 Oracle Forms 的 Summit demo 迁到 Java、Vaadin 和 Spring Boot，关键在流程。我第一反应是问旧系统被读懂了吗，新系统被验证了吗。

以前看企业软件迁移，总像修老房子。Oracle Forms 把界面、触发器、PL/SQL 逻辑、菜单、库文件捆在一起。报道里说作者第一份工作是在 Oracle Forms 6 里写模块，几年后要整体迁移。很多客户被支持、人才、集成、云化逼着动。

从数据来看，两周很抓眼球，但样本不大。它更像一次可重复工作流的演示，让 AI 读旧模块，拆触发器，生成 Java 代码，再用测试兜住。GitHub 上已有 MCP server 读 .fmb、.mmb、.pll、.olb，解决模型进不了 Forms Builder 的尴尬。这个赛道真正卡人的是能不能把老资产变成机器可消费的结构。

现在迁移工具大概分三层。一层是确定性转换器，强调同一个源构造走同一条转换规则，十个、五百个、两千个表单都按规矩来。另一层是 AI 辅助平台，擅长总结、解释、生成测试、找依赖。还有一层是服务商的混合流程，把评估、转换、QA、切换排成周期。有服务商给百万行代码项目的典型周期里，评估和 PoC 两周，自动转换和测试生成四到八周，迭代 QA 四到六周，切换两周。数字不一定适合所有公司。钱主要花在验证和割接上，生成代码那一下占比没那么高。

我之前觉得 AI 做代码粗筛和测试辅助就够了，生产级补丁不能直接合并。现在想法没怎么变，只是更具体。迁移场景里，AI 最该干的是脏活，读旧界面，列触发器，标依赖，生成等价测试，把人工审查从对着老代码猜变成对着差异清单确认。如果它跳过审查，直接给一个能跑的 Java 壳子，风险反而更大。业务逻辑藏在 Oracle Forms 的事件里，不在 UI 里。

企业软件迁移要搬走十几年甚至二十年的规则。搬错一个金额校验，财务系统就找上门。

这个赛道的关键点是可验证的等价性。能否证明新系统在同样输入、权限、数据下给出同样业务行为，这比 prompt 漂亮和上下文大小更影响验收。测试资产、数据回放、差异报告听起来不性感，却决定验收。

往后看，我倾向于一个判断。未来十二个月，AI 不会淘汰传统迁移服务商，但会拆开他们的报价结构。纯代码生成会迅速贬值，能解析 Oracle Forms、ERP、COBOL 等老资产，并能输出可审计迁移包的中间工具，会先拿到预算。大模型负责理解，确定性工具负责规则，人工负责签字。这个分工比一键迁移更接近商业现实。

---

📌 本文编译自 Hacker News，原文：https://vaadin.com/blog/oracle-forms-to-java-a-two-week-ai-migration-experiment

版权归原作者所有，本文为基于公开报道的编译与独立分析。