一、为什么旧系统不能按“改几个功能”直接报价
同样是“给老 ERP 增加移动审批”，可能有三种完全不同的现实：
- 系统结构清楚、接口完整，增加一个独立模块即可；
- 审批规则散落在多个页面和存储过程中，需要先梳理；
- 原系统已经无法安全扩展，任何修改都可能影响财务或库存数据。
影响旧系统改造费用的，不只是新需求，还包括：
- 是否拿得到完整源码和构建环境；
- 技术栈是否仍有稳定维护；
- 数据库结构和业务口径是否清楚；
- 系统之间有多少接口；
- 是否有自动化测试；
- 生产环境能否做备份和回滚；
- 业务是否允许停机；
- 历史数据要保留多少；
- 原厂商或原开发人员是否配合；
- 上线后是否需要新旧系统并行。
任何人在不了解这些信息时给出的“一口价”，本质上都包含大量假设。假设错了，要么不断加价，要么通过降低质量消化风险。
二、先做一轮只读审计，至少看六个方面
只读审计的目标不是立刻修改代码，而是把未知问题变成可以决策的清单。
1. 业务审计
梳理系统目前真正支撑的业务：
- 哪些流程每天都在用；
- 哪些功能已经停用；
- 哪些操作依赖线下补充；
- 哪些报表决定经营和财务判断；
- 哪些规则只存在于老员工经验中；
- 哪些问题正在影响客户、订单或回款。
旧系统里最值钱的往往不是代码，而是已经运行多年的业务规则。
2. 代码审计
重点确认：
- 项目能否完整构建；
- 代码仓库是否与生产版本一致；
- 模块之间耦合程度；
- 关键业务逻辑的位置；
- 已知漏洞和过期依赖；
- 是否存在大量复制代码和临时补丁；
- 是否有测试和基础文档。
代码“老”不一定要重写。真正需要警惕的是无法构建、无法定位、无法测试和无法安全发布。
3. 数据审计
检查：
- 关键业务表；
- 数据量和增长速度；
- 重复、缺失和异常数据；
- 字段口径；
- 历史状态；
- 附件和非结构化文件；
- 备份与恢复能力。
很多改造项目最后不是卡在新页面，而是卡在“旧数据到底怎样解释”。
4. 接口审计
列出所有外部和内部连接：
- 财务、ERP、CRM、WMS 等系统；
- 微信、支付、短信、地图和物流；
- 硬件、扫码枪、打印机和设备；
- Excel、邮件和人工导入导出；
- 定时任务和数据同步脚本。
接口文档缺失时，还要确认真实请求、认证方式、重试、异常补偿和数据对账。
5. 环境与运维审计
需要知道系统怎样部署、怎样监控、怎样备份，以及发生故障时谁能恢复。
特别要检查：
- 操作系统和运行时版本；
- 服务器和数据库资源；
- 域名、证书和开放端口；
- 日志是否完整；
- 是否有告警；
- 备份能否恢复；
- 发布是否可以回滚。
6. 组织和责任审计
系统问题不一定都来自技术。还要确认：
- 谁负责需求决策；
- 谁解释业务口径；
- 谁拥有账号和数据权限；
- 哪些部门会受改造影响；
- 谁负责最终验收；
- 上线后由谁维护。
如果这些问题没有负责人，换一套新系统也可能再次失控。
对于已经烂尾或准备换团队的项目，可以先参考《外包团队失控后怎么接手？我为什么先做 7 天只读审计》。
三、路线一：继续修补，什么时候最划算
继续修补不是“什么都不改”，而是在现有结构上解决明确问题。
适合继续修的情况
- 系统仍然稳定运行；
- 核心业务规则清楚；
- 源码和环境可构建；
- 问题集中在少数模块；
- 技术栈虽然旧，但短期仍可维护；
- 企业近期无法承受大规模切换；
- 新需求可以通过独立模块或接口实现。
成本主要花在哪里
- 修复明确缺陷；
- 补日志、监控和备份；
- 升级高风险依赖；
- 增加必要接口；
- 优化慢查询或大数据量操作；
- 补齐部署和运维文档；
- 为后续改造增加最小测试保护。
主要风险
局部修改仍受原结构限制。每增加一个需求，都可能需要绕过旧设计，长期维护成本会逐渐上升。
因此，继续修更适合“先止血、保业务”，不适合无限期拖延结构性问题。
四、路线二：局部重构，通常是多数企业的现实选择
局部重构是把高风险、高变化或高价值模块逐步替换，而不是一次推倒全部系统。
适合局部重构的情况
- 核心业务仍有价值；
- 某些模块已经严重拖累迭代；
- 数据需要保留；
- 业务不能长时间停机；
- 企业希望分阶段投入；
- 新旧技术可以通过接口暂时共存。
常见重构顺序
- 先补监控、日志、备份和发布能力；
- 把身份、权限或接口入口统一；
- 将变化最快的业务模块独立出来；
- 建立新旧系统之间的数据同步或调用边界；
- 按业务流程逐步迁移用户；
- 确认旧模块无人使用后再下线。
这种方式常被称为“渐进式替换”。老板不必记住术语，只要记住原则：新系统每上线一块，旧系统就少承担一块，而不是长期维护两套完整业务。
成本主要花在哪里
- 旧逻辑梳理；
- 模块边界设计；
- 接口和数据同步；
- 新模块开发；
- 新旧流程并行；
- 数据校验；
- 分批培训和切换；
- 长期过渡期维护。
主要风险
如果没有明确的退出计划，新旧系统可能长期并存，接口越来越多，最终比原系统更复杂。
局部重构必须为每个阶段写清：迁哪些用户、迁哪些数据、什么时候关闭旧入口。
五、路线三：整体替换，什么情况下反而更便宜
整体替换并不意味着复制旧系统的所有功能。真正合理的做法，是保留仍有价值的业务规则，重新设计核心流程和数据模型。
适合整体替换的情况
- 源码缺失或无法构建；
- 核心组件已经无法安全维护；
- 数据结构严重混乱；
- 多年补丁导致任何修改都高风险；
- 业务模式已经发生根本变化；
- 现有系统无法满足安全、审计或稳定要求；
- 继续修补的年度成本接近新系统投入。
成本主要花在哪里
- 业务重新梳理；
- 新产品和系统设计；
- 新系统开发或采购；
- 历史数据清洗与迁移；
- 新旧系统接口；
- 用户培训；
- 试运行与双轨验证；
- 正式切换和旧系统归档。
主要风险
整体替换最大的风险，是把旧系统所有功能原样复制，连多年积累的无效流程也一起重做。
重做之前应把功能分为四类：
- 必须保留；
- 需要优化；
- 可以用成熟产品替代；
- 应该直接删除。
只有这样，整体替换才是重建，而不是昂贵的翻版。
六、三种方案的成本怎么比较
旧系统改造不适合只比较一次性开发费。更有用的是看未来两到三年的总成本。
可以按下面的公式评估：
总成本 = 审计与方案 + 开发或采购 + 数据迁移 + 接口联调 + 测试切换 + 培训运维 + 双系统过渡 + 失败风险
| 比较项 | 继续修补 | 局部重构 | 整体替换 |
|---|---|---|---|
| 初始投入 | 较低 | 中等、可分阶段 | 较高 |
| 上线速度 | 快 | 分阶段见效 | 较慢 |
| 对业务影响 | 小 | 可控 | 较大 |
| 历史包袱 | 大部分保留 | 逐步减少 | 可显著清理 |
| 数据迁移 | 少 | 分批迁移 | 全面规划 |
| 长期维护 | 可能继续上升 | 有机会逐步下降 | 取决于新方案质量 |
| 主要风险 | 越修越复杂 | 新旧系统长期并存 | 大范围切换失败 |
表里的“高低”只是相对关系。一个规模很小但完全失控的系统，整体替换可能比局部重构更便宜；一个运行稳定的大型系统，继续修补和外围扩展可能更合理。
七、可以用四个指标做决策
1. 业务适配度
现有系统还能覆盖多少核心业务？如果业务已经完全变化，继续补功能的价值有限。
2. 技术可维护性
系统是否能构建、测试、发布、监控和恢复？如果每次修改都靠某个人记忆，维护风险已经很高。
3. 数据可信度
关键数据是否完整、口径是否一致、关联是否可解释？数据问题没有解决时，新旧方案都会受影响。
4. 未来变化频率
业务未来是否会频繁调整？变化越快，越需要清晰模块和接口边界。
可以给每项按 1—5 分评价：
- 业务适配度越低，越倾向替换；
- 技术可维护性越低，越倾向重构或替换；
- 数据可信度越低，越要先做数据治理；
- 未来变化频率越高，越不能继续堆临时补丁。
八、预算应该分阶段，而不是一次押完
更稳妥的预算顺序通常是：
第一阶段：审计与止血
确认代码、数据、接口和环境，先解决备份、严重故障和安全风险。
第二阶段：方案验证
选择一个高价值流程，做小范围重构或新模块，验证技术路线和切换方式。
第三阶段：分批迁移
按部门、用户、区域或业务模块推进，保留回滚能力。
第四阶段：收口与下线
完成数据归档、账号收回、接口关闭和旧环境退役，避免长期重复付费。
每一阶段都应该有可独立验收的结果。项目如果中途暂停，企业仍然要拿到审计资料、代码、数据和可运行版本。
九、数据迁移经常是最大的不确定项
旧系统升级时，最容易被低估的是数据：
- 同一个客户可能有多个编号；
- 历史字段含义发生过变化；
- 金额和状态由人工修正；
- 附件散落在服务器和个人电脑；
- 新旧系统的业务对象并不一一对应；
- 旧系统缺少完整导出能力。
数据迁移应单独盘点、映射、清洗、试迁移和校验，不要把它写成报价单里一句“含数据导入”。
详细方法可以阅读《老系统数据迁移怎么报价？》。
十、上线切换必须保留退路
根据业务连续性，可以选择：
停机切换
适合业务量较小、可安排明确停机窗口的系统。优点是边界清楚，缺点是切换失败会直接影响业务。
预迁移加增量同步
先迁大部分历史数据，上线前再同步新增和变化数据，缩短停机时间。
新旧系统双轨运行
在有限时间内同时运行，通过数据对账确认新系统稳定。双轨时间不能无限延长，否则操作人员会在两套系统重复录入。
无论采用哪种方式，都要提前定义：
- 切换负责人；
- 停止旧系统写入的时间；
- 最终数据校验；
- 成功标准；
- 回滚触发条件；
- 回滚后的数据处理。
十一、拿到改造报价后，继续追问这八件事
- 报价基于哪些已经验证的事实？
- 哪些风险仍然无法确认？
- 数据迁移包含哪些表、年份和附件？
- 新旧系统需要并行多久？
- 哪些接口需要原厂商配合？
- 测试和回滚怎样做？
- 改造过程中新增需求怎样处理？
- 完成后哪些旧组件、服务器和费用可以关闭？
能坦白列出未知项的方案，通常比承诺“一次全部解决”的方案更可靠。
常见问题
旧系统没有源码，还能改造吗？
可以先评估数据库、接口、页面行为和数据导出能力，但未必能直接修改原系统。很多情况下需要做外围系统、数据迁移或整体替换。
原开发公司不配合怎么办？
先确认合同、账号、服务器、域名、数据库、仓库和备份的实际控制权。技术团队可以评估可接管程度，但权属和合同问题应由企业结合专业法律意见处理。
是不是换成最新技术就算升级？
不是。技术栈更新如果没有改善业务流程、维护能力、稳定性和数据质量，只是重新写了一遍代码。
旧系统还能运行，为什么要现在改？
不是所有旧系统都要改。真正需要行动的信号包括：严重故障频繁、核心人员依赖、无法满足新业务、数据长期不可信、安全风险无法修复，或每次小改都越来越贵。
能不能一边正常使用一边重构？
可以，也是很多企业更现实的选择。但必须设计模块边界、数据同步、版本兼容和回滚方式，并限制双轨运行时间。
参考来源与口径说明
本文的成本区间和三条改造路线用于立项比较，不是统一行业报价；旧系统必须在只读审计后，结合代码、数据、接口、环境和停机窗口重新估算。关于配置基线、变更审批、影响分析、验证和回滚控制，可参考 NIST 的Guide for Security-Focused Configuration Management of Information Systems。该来源支持“先建立基线、再受控改造”的方法，不替代具体系统审计。
结语：先花小钱买清楚，再决定是否投入大钱
旧系统升级改造没有统一价格。继续修、局部重构和整体替换，都可能是最省钱的方案，也都可能因为判断错误变成最贵的方案。
正确顺序是：先审计现状，确认业务、代码、数据、接口和环境，再把三条路线放在同一张总成本表里。不要用一次性开发报价替代长期维护和切换风险。
如果你正在处理旧 ERP、CRM、管理后台或烂尾项目，可以查看华茂思捷的系统重构、项目接手与技术顾问服务。也可以通过联系页面提交现有资料，先做只读范围核对，再判断应该继续修、局部重构还是整体替换。
更多项目风险与预算判断，可浏览老板必读栏目。
