一家做五金批发的客户找了十年前的供应商写的进销存，现在改个促销规则要等一周，报价是同类新功能的三倍，可系统里躺着十几万条客户数据和六年订单，扔又不敢扔。老系统是很多企业的两难：改不动，又离不开。后端系统开发的改造，路线选对了能救，选错了等于二次买单。
三条路各自的代价
第一条是原样续命：小修小补，能跑就行。优点是省钱省事，缺点是窟窿越来越大，安全隐患、性能瓶颈、人员断档全都拖着，等于把问题留给未来更贵的自己。第二条是推倒重写，听着痛快，风险最大：十年积累的业务规则全藏在代码和老员工脑子里，新系统第一年对不上账、流程跑偏是常事，重写烂尾的案例比改造成功的多。第三条是渐进式改造，新需求做在新模块里，老模块逐个迁移，两条腿走路，风险分摊，多数企业适合这条，它也是后端系统开发改造里失败率最低的走法。
动手前先做三件事
- 把家底盘清楚：数据库表结构、核心业务流程、和哪些外部系统有牵连，整理成文档，没这份底稿，任何改造都是闭眼开车；
- 找出风险最集中的模块：哪些功能出错代价最大、哪些代码最没人敢碰，改造从它们排序，而不是从最容易的做起；
- 冻结老系统的需求：改造期间老系统只修致命bug，不加新功能，否则两边同时开工，永远收不了尾。
渐进式改造的通俗理解：不是翻新整栋楼，而是逐个房间装修，住人不间断。新订单模块先上线试运行，老的照常跑，数据打通验证没问题后切换，再动下一个模块。每一步都可回退，出了问题不伤全局。
改造的预算有个粗略参照：完整改造大概是重写的一半到三分之一，分两到三年投入。比一次性砸一笔重写的钱压力小得多，而且每阶段都有可见产出，老板能看得见进展，项目不容易半路断粮。还有一点常被忽略：趁改造把文档和权限体系补齐，否则新系统过十年又是一套没人敢动的老系统。
先评估再拍板
改造还是重写，不是拍脑袋的事，取决于代码质量、业务规则清晰度、数据迁移难度三个变量。花几千块请第三方做一次评估，把三条路线的工期、预算、风险摆成对比表，决策质量完全不同。
两条建议：先花小钱做评估再定路线，别被任何一方的报价单推着走；选改造路线的，找一个能长期陪跑的团队，改造最忌讳每两年换一拨人。比格网络接过不少十年老系统的改造，第一步永远是摸清家底再出方案，路选对，钱才花在刀刃上。
