老旧系统改造：别再想着推倒重来了

一个你可能很熟悉的故事

某制造企业的ERP系统跑了12年，基于Java EE 6 + Oracle数据库。维护团队2人，加上Oracle授权费，每年运营成本约50-60万。懂原始业务逻辑的工程师大多已离职，文档残缺。

两年前，管理层决定重写，外包给一家软件公司，6人团队，计划14个月交付，预算约250万。

实际情况：

• 前10个月，主流程基本跑通，但大量边缘业务逻辑没有覆盖——旧系统里这些逻辑没有任何文档，新团队只能反复从旧代码里挖，每翻出一个就要评估要不要实现。
• 第14个月没能上线，推迟到第18个月，追加了约60万预算。
• 上线后两个月内，业务部门反馈了30多条"旧系统里没有这个问题"的bug，其中十几条影响日常操作。
• 半年后，部分统计报表模块仍在用旧系统取数，新旧并存状态至今没有完全结束。

这不算一个特别糟糕的项目——没有烂尾，核心功能上线了。只是代价超出了预期，技术债以另一种形式延续下来。这种结局，在企业IT圈子里其实很常见。

全量重写为什么总是失败

不是团队不行，不是预算不够，而是这个模型本身有结构性缺陷：

• 知识转移的不可能性：旧系统里积累了十几年的业务逻辑，大部分没有文档，只存在于老员工的记忆和代码里。重写时，这些知识要被重新发现——发现的方式是"新系统上线，出现奇怪的bug，然后有人说'啊，原来的系统有个特殊处理……'"。
• 估期幻觉："18个月"的估期，是在没有真正读完旧代码的情况下给出的。真正开始做了，才发现不知道有多少隐藏逻辑。所以每个项目都超期，而且超的幅度比预计还大。
• 业务不等人：你花两年重建一个18个月前的系统。上线那天，业务需求已经变了。你的"新系统"一开始就是落后的。
• 并行运营成本：重写期间，旧系统还在跑，还需要维护。你在同时支撑两套系统的成本。

增量迁移是什么

不是"逐步重写"，而是更精确的方式：

1. 把旧系统切分成相对独立的模块（不是按代码文件，而是按业务边界）
2. 选择一个合适的模块优先迁移（有价值但非核心，有清晰的输入输出边界）
3. 在新技术栈上重建这个模块，同时构建行为等价测试（新旧模块给相同输入，验证输出一致）
4. 双写灰度：两套并行运行，旧的对外，新的在后台验证，对比差异
5. 差异归零后，流量逐步切到新模块（5%→25%→100%）
6. 确认稳定后，删除旧模块代码
7. 下一个模块

每个模块3-6周，从开始到稳定生产运行。不需要停机，不需要"一次性上线"，业务方感受到的是渐进的改善而不是一次豪赌。

AI在哪些步骤提速最明显

增量迁移的这个方式，在没有AI工具之前也存在，但成本相对高。AI主要在两个地方把成本压下来：

步骤1：AI辅助文档化旧系统

旧系统没有文档是最大的迁移障碍。过去，这需要一个资深架构师花4-6周阅读代码、访谈老员工、画架构图。

现在，把旧代码喂给大模型（Claude等长上下文模型），让它生成：

• 每个模块的功能描述和边界分析
• API接口的行为规范（输入、输出、错误情况）
• 模块间的依赖关系图
• 数据流向和状态变更逻辑

AI生成的文档不是100%准确，但1-2个熟悉系统的人花1-2天校验，已经比过去的"口口相传"强得多。而且这个文档会成为后续所有迁移工作的基准。

步骤3：AI辅助在新栈上重建

有了文档后，在新技术栈上重建是AI最擅长的工作：

• 把旧模块的行为规范给AI，让它生成新栈的等价实现
• 让AI自动生成行为等价测试套件
• 开发者重点做的是：架构判断、安全边界、性能瓶颈——这些是AI目前替代不了的部分

一个典型的API接口迁移，过去可能需要2-3天（阅读旧代码1天+实现新代码1天+测试1天），现在大约需要半天到1天。乘以几百个接口，总工时缩减显著。

成本结构的对比

以一个中型业务系统（约100-200个接口，4-6个主要业务模块）为例，粗略对比：

方式	时间	成本参考	主要风险
全量重写	12-24个月	150-400万	交付不确定性高；隐藏业务逻辑难以完整还原；上线后存在磨合期
AI辅助增量迁移（先做2个模块）	2-4个月	20-50万	低；每个模块独立交付，随时可停；不影响现有系统运行

增量迁移的另一个优势：它是可中止的。迁移完两个模块后，如果投入产出比低于预期，可以停下来——已迁移的部分独立运行，原系统其余部分照常。你不是在做一个"要么全投、要么烂尾"的赌注，而是在做一系列可以独立评估的投资。

哪些系统不适合增量迁移

坦白说：

• 系统本身就是错的（架构根本上有问题，不是技术栈老的问题）：这种情况下，增量迁移是把错误的东西用新方式重写了一遍，没有意义。需要先重新设计。
• 模块边界完全纠缠无法切分：这种系统确实存在，迁移前需要先做一轮内部解耦。
• 核心数据模型本身需要大幅变更：数据迁移和代码迁移同时做，风险叠加，需要更谨慎的计划。

下一步

如果你有一个运行多年、维护成本越来越高的旧系统，第一步是对它做一次结构评估——哪些模块相对独立，哪个模块先迁移价值最大，现有的测试覆盖度怎么样。

BCD 专注于这类 AI 辅助增量迁移。查看老旧系统改造服务，或者预约一次对谈，把你的系统状况和迁移目标聊清楚。