原开发方不维护了，换团队前先做什么接手评估

原开发方不维护了，先别急着找人报一个“接手价”。我要先分清：系统正在正常使用，只缺后续维护；还是已经停了，需要救急。两种情况的安排不同。真正决定能否接手的，是资料和权限是否齐全、代码能否重建、数据能否恢复，以及最重要的业务现在靠什么运行。先做一轮有边界的评估，再谈维护合同，通常比直接承诺全部接管更稳妥。

先让业务活着，再讨论换技术

如果旧系统还能接单、查库存，评估期间先保留现状。不要因为新团队觉得技术旧，就马上停服务器、注销账号或大规模升级。旧系统此刻可能是唯一能读懂历史数据的地方。

若已经停机，先列出今天必须完成的三件事，例如查订单、开送货单、记录收款；同时准备临时表格记录新增业务。救急的目标是避免数据继续散失，未必立刻修好所有页面。对外沟通时把恢复关键业务与后续优化分成两份工作，别把一个紧急故障变成没有边界的重建项目。

交接材料要能使用，不只是有一个压缩包

代码文件不是全部资产。至少还要知道数据库在哪里、怎么备份、部署需要什么环境、邮件或支付由谁提供。第三方账号可能由客户自管，也可能由服务方托管；需要确认授权、操作权限和退出安排，不能看到一个后台就认定所有权已经转移。

先做目录清单，不必把密码和完整客户数据库发到聊天里。确需检查时，再安排受控授权和必要的脱敏副本。对方提供的“备份”也要试着恢复；无法还原的数据包，不能算完成了交接。

让新团队做一个小范围的运行验证

可以约定一个具体评估范围：在隔离的测试环境启动系统，用模拟账号完成一条订单流程，核对导出的字段，再记录失败处。测试数据不要直接回写正式系统，更不要借评估顺便给客户群发通知。

交付物应是一份可以阅读的结论：能启动什么、缺什么、最危险的依赖是什么、哪些事项还没查清。即使暂时不能估出全部改造费用，也应能区分“资料补齐后可维护”和“核心组件不可获得”。如果评估只覆盖了一条流程，报告应明确这个范围，其余模块留待后续核对。

按证据选择维护、局部替换或重建

模拟情境：一家企业的订单录入正常，但旧打印组件无法在新电脑运行。如果订单数据、页面和接口可用，先替换打印这一段，可能比重做全部系统更合适。相反，只有电脑里的安装程序，没有数据库说明和合法修改权限，就需要先确认数据导出及使用授权。

重建也不代表历史问题自动消失。新旧字段如何对应、旧订单如何查询、谁确认迁移结果，都要列进范围。对无法恢复的旧数据，应记录缺口，不能用随意补出来的数字填平账目。评估中发现的未知事项，应该成为下一步验证任务，而不是藏进固定总价。

交接完成的标志，是换人后还能处理事情

请原团队和新团队共同确认一次截止时点：此时之前由谁负责，之后故障报给谁。保留正式备份、版本标记、账号权限清单和恢复步骤，并撤销不再需要的临时权限。托管资源如何迁出、费用何时结清，也要提前说清。

我建议首次沟通只带系统用途、当前故障、现有资料目录和最重要的一条业务流程。银背现有作品可以帮助你判断技术与业务是否接近；是否接得住你的系统，仍要经过实际评估。能维护、能迁出、能换人，应该各有可验证的交接结果。

你的下一步

查看真实作品/合作范围，再提交最小需求说明；不用先发业务机密。

查看银背已公开的项目案例，按相似业务核对具体做过的范围。