旧系统还能跑但写它的人找不到了，怎么办？我劝你先别急着重写

去年十月有个客户找到我，开口第一句是："程序还能跑，就是写它的人联系不上了。"这是个跑了八年的 WinForms 进销存，.NET Framework 3.5，数据库是 SQL Server 2008，全公司四十多号人每天靠它开单。他问我能不能"升级一下"，我问他预算里的期望是什么，他说"花小钱，把界面改成网页那种"。

我把话放在前面：这种活，大部分时候重写是个坑，直接不动也是个坑。真正该做的是先花一两天做个体检，然后从三条路线里选一条。下面把我这些年处理这类系统的经验拆开讲。

先做体检，再谈路线

体检就四件事。第一，源码全不全。我接过一个项目，客户手里只有一个压缩包，解开后解决方案能打开，但 Utilities 文件夹整个是空的——原作者把通用工具类单独放在外面，从来没进过版本库。这种情况下编译都过不了。第二，第三方依赖还活着吗。老项目常用 DevExpress、FineUI 这类控件，如果 license 丢了、官网也不再提供老版本下载，光是把项目编译通过就要花好几天。第三，数据库有没有文档。没有文档就开 SQL Server Profiler 跟两天业务操作，把每张表被谁读写记下来，这一步省不了。第四，运行环境还能复制吗。有个客户的系统绑死了加密狗驱动和一台老型号扫码枪，Win10 上驱动装不上，只能在留着 Win7 的虚拟机里跑——这种约束直接决定后面选哪条路。

路线一：包一层，老系统原地不动

大部分"还能用"的系统，真正的痛点不是功能不够，是数据出不来、报表做不了、跟新系统对不上。这种情况根本不用碰老代码，在旁边包一层就行：写个 Windows 服务定时把它的数据库同步到一套干净的表结构里，报表、查询、老板要的手机上看数据，全在新的这层做。

我 2022 年给一家做仓储的客户就是这么干的。他们的入库系统是 2014 年的 WinForms，改不动，但每天出入库的流水数据就躺在那台 SQL Server 里。我做了一个 .NET 6 的小服务，每小时增量同步一次到新的库，WPF 写了个查询端 + 一个微信小程序给老板看库存。老系统一行代码没动，三周的活，收款也顺——因为客户每周都能看到新东西出来。

这条路的好处是风险最低、见效最快；坏处是老系统本身的问题一个都没解决，该崩还是会崩，你只是把"看得见的价值"先交付了。

路线二：绞杀式替换，一块一块啃

如果业务还在长、老系统已经开始挡路（比如要对接的电商平台它根本没有接口），那就走逐步替换：新功能全部在新系统做，老系统保持只读或半退役，数据按模块迁。关键是别想着"大爆炸式"一次切换——我见过一个同行替客户重写整个 ERP，写了十个月，上线那天才发现财务模块里藏着几十条硬编码的税务规则，老系统里维护它们的人早就离职了，最后项目烂在那。

绞杀式的正确姿势是：先把老系统里最常改的模块挑出来重做（通常是报表和对外接口），然后是录入类模块，最后才是核心账务。每迁一块，让业务人员并行跑两周再切。慢是慢，但每一步都能停下来，不会押上全部。

路线三：整体重写，只有一种情况值得

只有当体检结果同时满足三条——源码残缺到补不齐、运行环境即将消失（比如 must 跑在 Win7 上而公司要全面换 Win11）、业务规则已经还原不出来——才考虑整体重写。而重写前要跟甲方把一笔账算清楚：重写的钱不是写代码的钱，是"把散落在老代码、老员工脑子、八年聊天记录里的业务规则重新整理出来"的钱。这笔钱通常是纯开发工时的 1.5 到 2 倍。

报价的时候我就明说：这个项目一半的钱付给"搞清楚它到底在干什么"。甲方如果接受不了，那这个活我不接——接了大概率烂尾，对双方都是消耗。

写在最后

旧系统三个字背后，甲方真正想要的往往不是"新系统"，而是"确定感"：知道它还能撑多久、出事了找谁、往哪个方向投钱不浪费。你把体检报告和三条路线的代价摆在他面前，让他自己做选择，比一句"建议重写"值钱得多。而对你自己来说，"会处理遗留系统"这个标签，比"会写新代码"稀缺得多——新项目谁都能接，烂摊子不是谁都敢碰。

有定制软件需求（.NET 桌面端 / 小程序 / APP），直接联系：微信/手机 17788568694

---

手机 17788568694 ｜ 微信 17788568694（与手机同号）｜ QQ 76656825