遗留系统代码迁移

1客户嘴上要的

「核心业务系统是 15 年前的老 Java 加几百个 Oracle 存储过程，要迁到国产数据库和新框架。用 AI 把代码自动翻译过去，半年完成。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 12 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1–2

   第 1–2 周找真问题（先弄清楚老系统在做什么）

   • 跟架构师、2 个维护老系统的开发、1 个业务系统的业务负责人坐，过一遍系统的模块清单和生产运行情况。发现：620 个存储过程里，有 180 个近一年没有被调用过；核心的结算、计费逻辑集中在 40 个存储过程里，里面有大量「特殊客户」「历史补丁」的分支，没有文档也没有测试。
   • 真问题是「业务规则不可见 + 没有判断迁移对错的方法」，不是「翻译速度」。成功标准改成：「核心 40 个存储过程，在 3 个月的生产数据回放中，新旧系统输出逐条一致；不一致的每一条都有业务负责人签字确认的原因。」
   • 踩坑别按代码行数报进度。「翻译完成 80%」没有意义，能证明一致的部分才算完成。
2. 3–4

   第 3–4 周用 AI 读代码，不急着写代码

   • 用模型对 40 个核心存储过程做「业务规则抽取」：每个分支在什么条件下触发、做了什么计算。生成的规则清单交给业务负责人逐条确认，发现 7 条规则业务已经不用了，3 条和现行合同不一致。
   • 结合数据库的执行统计和调用日志，把 180 个不再调用的存储过程列为「下线候选」，由业务和运维确认后不迁移。
   • 踩坑AI 抽取的规则一定要人确认。模型会把读不懂的代码「合理化」成一条看起来正确的规则。
3. 5–7

   第 5–7 周先建对照测试，再迁移

   • 搭「回放对照」环境：从生产库脱敏导出 3 个月的输入数据，同时在老系统和新系统上运行，自动比对每一条输出。
   • 再开始迁移：按模块用 AI 生成新代码，开发评审后跑对照测试，不一致的自动生成差异报告，标出对应的规则。
   • evals 就是对照测试的一致率，按模块统计；国产数据库的数值精度、日期函数、空值处理和 Oracle 不同，这类差异单独归类。
   • 踩坑脱敏会改变数据分布，导致一些分支跑不到。要检查回放数据覆盖了规则清单中的哪些分支，没覆盖的补造测试用例。
4. 8–10

   第 8–10 周一个模块切换试点

   • 选一个风险中等的模块（如账单生成），新旧系统并行运行一个结算周期，每天比对。业务负责人每天看差异报告，确认后才切换。
   • 开发反馈：「差异报告直接定位到规则，原来查一个差异要半天」——把报告接入缺陷管理系统。
5. 11–12

   第 11–12 周交接交接

   • 交给架构师和系统维护团队：规则清单作为新系统的业务文档，对照测试作为回归测试持续运行。后续模块按同一流程迁移，FDE 不在场也能推进。
   • 周期长的原因：要等完整的结算周期验证。没有规则清单和对照测试，后续模块又会回到「翻译完了不敢上线」。

4这个案例教给你的可复用判断