老系统用了十年，重写还是渐进改造？
用了十年的老系统，界面旧、维护难、新人不敢动，但它撑着公司每天的核心业务。推倒重写怕翻车，继续将就又怕哪天撑不住。这篇文章把"重写还是渐进改造"这道选择题的判断标准讲清楚，帮你在不停摆的前提下完成系统换代。
公司用了十年的老管理系统问题越来越多，应该推倒重写，还是在原系统上渐进改造？怎么判断？
判断标准不在系统年龄，而在三件事：第一，技术栈是否还有人维护、能否招到人，技术栈死了的系统没有渐进改造的资格，只能规划替换；第二，业务逻辑是否沉淀在代码里且无人说得清，若逻辑文档缺失、全靠老员工记忆，重写反而是重新梳理业务的机会；第三，系统是否还能支撑未来两三年的业务变化。多数情况下的正确答案是"渐进替换"而非二选一：不动老系统的核心运转，把新需求、新模块建在新架构上，通过接口与老系统并行，再按模块逐个迁移，最后整体切换。这种方式业务不停摆、风险可回退，每一步都可验证。只有技术栈彻底死亡、且业务逻辑已被完整梳理出来的情况，才值得考虑一次性重写。
# 老系统用了十年，重写还是渐进改造？
"这套系统是公司刚起步那年上的，现在界面像上个时代，想加功能找不到敢改的人，但财务、仓储、销售每天全靠它跑。"
这是存量企业最真实的处境。老系统像一栋住了十年的老房子：结构还能住，但水管电线都开始老化，想翻新，又怕拆了没地方住。
"重写还是改造"这个问题，我们先给结论：大多数情况下，正确答案不是二选一，而是第三条路——渐进替换。 先把判断标准讲清楚。
## 先回答三个诊断问题
一、技术栈死了吗？
技术栈"死"的标志：主流厂商停止维护、安全补丁断更、市场上几乎招不到会这套技术的人。技术栈死了的系统，没有渐进改造的资格——你在一个没人会修的地基上做装修，花的每一分钱都在贬值。这种情况要规划的是替换，问题只剩怎么替。
二、业务逻辑还在人脑里吗？
十年的系统，代码里沉淀了大量业务规则：特殊客户的计价方式、跨年数据的处理口径、各种"当时为什么要这么做"的历史补丁。如果这些逻辑没有文档、全靠一两个老员工记着，那么重写反而是好事——它逼着公司把业务逻辑重新梳理一遍、落成文档。反之，如果逻辑清晰、文档完整，渐进改造的底子就在。
三、它还撑得住未来两三年的业务吗？
不是问"现在能不能用"，而是问"接下来要做的事它还能不能接"：要不要对接新渠道？要不要给管理层实时数据？要不要接 AI 能力？老系统真正的风险不是某一天突然崩掉，而是业务想跑的时候，系统拖住腿。
## 为什么一次性重写通常是坏答案
推倒重写的诱惑很大：一切全新，没有历史包袱。但行业里重写翻车的故事远多于成功的：
- 范围失控：新系统要覆盖老系统十年的功能积累，做到一半才发现"原来还有这个功能"
- 双轨期煎熬：重写期间老系统还得维护，等于养两套班子
- 切换即事故：一次性切换当天，十年踩过的坑会以bug形式重新出现一遍
- 最大风险：重写项目失败的代价是整个公司停摆，没有退路
一次性重写只在两个条件同时成立时值得考虑：技术栈彻底死亡，且业务逻辑已被完整梳理成文档。缺一不可。
## 渐进替换：第三条路怎么走
渐进替换的核心是让新架构长在老系统旁边，而不是长在老系统里面：
1. 并行搭建：新模块、新需求一律建在新架构上，通过接口与老系统交换数据，老系统的核心运转一点都不动
2. 逐个迁移：按业务模块排迁移顺序，通常从边缘模块（报表、查询、移动端）开始，核心模块（财务、库存）最后动
3. 灰度切换：每个模块迁移后小范围试用、新旧并行验证，数据对得上再切
4. 整体收口：老系统退成只读的历史档案库，最后下线
这条路的好处是每一步都可验证、可回退，业务一秒都不停摆。代价是周期更长、需要服务商有清晰的整体架构规划——否则新架构也会长成新的"老系统"。
## 写在最后
老系统换代，本质不是技术工程，而是风险管理工程。谁把"业务不停摆"放在方案的第一位，谁才真正懂这件事的分量。
在协通的存量替换项目里，渐进替换是默认路径：先给老系统做一次完整的"体检"——技术栈评估、业务逻辑梳理、数据资产盘点——再输出分阶段的迁移路线图，每个阶段都有明确的验证标准和回退预案。十年系统承载的是十年业务，值得用稳妥的方式送走它。