旧系统还能用，只缺一个环节：加模块还是全部重做

旧系统还能稳定完成主要工作，只缺一个报表或审批环节，通常值得先检查能否配置或扩展，再考虑重做。决定方案的不是“新技术更好”，而是你能否合法取得所需数据、是否有稳定接口，以及两套系统出现差异时由谁负责。接口和权限没有看过之前，任何团队都不应保证一定能接，也不应靠直接改生产数据库来省事。

先写清要保留什么，不只写想增加什么

旧系统可能有一些平时看不见的价值：员工已经熟悉的操作、历史数据、与财务的约定，以及多年积累的异常处理。重做时这些都需要重新确认。先把“还能用”的范围列出来，避免为了一个缺口承担整套替换的迁移风险。

再挑一件具体需求，例如每天自动汇总未完成订单。问清需要哪些字段、允许多晚更新、谁会依据结果行动。有些需求用定期导出就够，有些必须接近实时；这两种条件对应的开发和维护成本不同。

下表可作为沟通表填写，不是对任何厂商系统的能力保证。由账号拥有者或原服务商提供信息，不需要把管理员密码交给新团队。无法确认的项直接标待确认。

先问原系统能否通过设置或已有模块完成。若不足，再评估外接功能；单纯查询和报表，有时可以从授权导出开始。需要写回订单或更改状态时，风险明显不同，必须处理重复、失败和权限，不能把读取成功当成整个接口接通。

全部替换适用于旧系统已经难以维护、多个关键流程持续受限，或扩展成本接近重新建设的情况。但“接近”要有明细比较，不能只凭感觉。把迁移、培训、并行期、历史查询和旧系统停用条件一并列入。

客户名称由哪个系统维护？订单金额改了以后听哪边的？如果两边都能随意修改，却没有清楚的冲突规则，增加模块可能制造更多重复工作。尽量让同一类数据有明确主来源，其他地方保留同步时间与异常提示。

同步失败时不能默默展示旧数字。让使用者知道数据更新时间、哪些记录未同步、是否需要人工处理。涉及付款、发货或权限变化的功能，尤其应先在测试环境验证失败和重试，不拿真实业务做试错材料。

试用后若决定不继续，新模块里产生的数据怎样取回，旧系统是否还能独立运作，都应有答案。不要让一个原本只负责报表的功能，悄悄成为原系统启动或登录的前提。

对于需要双向写入的方案，可以先限定对象和操作范围，再逐步开放。每次开放都说明谁批准、怎样撤销、异常如何停止。这个做法会增加前期核对工作，但比上线后才发现无法区分两边责任，更容易控制影响。

选择一类数据和一个只读任务，验证授权、字段、更新与结果核对。它的目的不是提前做出全部功能，而是尽早发现接入条件不成立。若原系统不开放必要能力或授权无法取得，应暂停依赖它的承诺，重新比较替代方案。

银背可以根据公开的企业系统服务范围参与需求讨论；能否接你的旧系统，要看实际文档、权限和运行条件。带原系统名称、脱敏字段样例和要解决的一个环节来评估，比直接要求“无缝打通全部系统”更容易得到可靠结论。

如果你也遇到类似问题，可以带一份脱敏流程或样表联系银背，先评估范围和能否承接。无需发送客户名单、真实订单或账号密码。