软件项目接管：30 天供应商切换计划

软件项目接管，是把一个线上产品的技术与运营责任，以受控方式转移给新团队。只有当新团队无需原供应商协助，也能构建、部署、观测、回滚和恢复系统时，接管才算完成。拿到代码仓库只是输入，不是验收。

本文专门回答切换过程该怎么做。完整的对外移交材料请看软件交接清单，更广泛的采购判断请看如何选择软件公司，如果需要团队实际完成评估并接管代码库，可了解 Wavect 的软件接管服务。

你是否应该更换软件供应商？

只有当继续合作的成本与风险高于切换成本与风险时，才应该更换。一次延期并不足以证明必须换人。更重要的是持续出现的运营模式：发布无法预测，同类缺陷反复出现，访问权限或文档仍由供应商控制，重大风险被隐藏，或商业激励已经不再符合产品需要。

在检查合同、使用权、通知期、付款状态、数据处理条款和实际访问权限前，不要宣布强制切换。权利或交付义务有争议时，请咨询合格律师。本文提供运营指导，不是法律意见。

新供应商获得访问权限前，应核查什么？

在开放生产凭证或客户数据前，先完成候选名单。2026 年 7 月，NIST 发布了 ICT 供应商尽职调查终版指南，评估维度包括来源、韧性、基础网络安全实践、供应链层级，以及所有权或控制等因素。这提醒采购方不要只看作品集，还要调查供应商如何工作。参见 NIST SP 1326 供应链尽职调查指南。

• 身份与责任。 哪个法律实体签约，谁领导接管，谁能访问生产，发生事故时谁做决定。
• 存量系统证据。 要求匿名评估报告、风险登记表或 30 天计划，而不只是新项目截图。
• 交付边界。 确认评估、稳定和后续开发是否由同一批关键人员负责。
• 安全实践。 询问访问如何审批、记录、复核和撤销，密钥如何处理，发现如何升级。
• 商业独立性。 即使不把后续工作交给该供应商，评估成果也应继续有用。

通过客户自有身份授予实名、限时、最小权限访问。能只读时先只读。不要用邮件发送密码清单。提前约定证据存放位置、可见人员和删除时间。

30 天软件接管计划

30 天是规划框架，不是适用于所有项目的承诺。小型 Web 产品可能更快，受监管平台、移动应用组合、工业系统或 24/7 产品可能需要并行团队与更长重叠期。顺序比日期更重要。

第 1 天前：写切换章程

客户、原供应商和新供应商各指定一名负责人。写清系统范围、紧急通道、变更权限、会议节奏、证据库、重叠窗口和独立性测试。区分正常退出与紧急退出。英国最新 Mid-Tier Contract 指南把退出管理视为合作期间持续准备的工作，包括维护虚拟资料库、退出计划、重新采购协助和终止协助。合同规模可以更小，但运营原则仍然适用。参见英国政府退出管理指南。

条件允许时，让原供应商承担明确且付费的切换职责。敌对交接会降低证据质量并提高业务风险。按具体材料与会议付费，记录未解决问题，不要把新团队的发现变成公开追责活动。

第 1 至 5 天：在不停机的前提下收回控制权

1. 先盘点，后轮换。 记录代码托管、云、DNS、证书、域名、应用商店、数据库、队列、邮件、分析、可观测性、支持工具、包仓库和商业许可。
2. 确认所有权。 记录法律账号持有人、账单负责人、管理员、恢复联系人和转移路径。
3. 保存证据。 制作经过授权的备份、导出和配置快照，保留审计日志与完整 Git 历史。
4. 按依赖顺序轮换。 先确认凭证被谁使用，再替换个人与共享凭证。回滚权限留在客户手中。
5. 记录生产基线。 捕获流量、错误率、延迟、队列、备份、未关闭事故、支持量和当前版本。

变更冻结应当有选择。暂停高风险路线图工作、schema 变更和基础设施重构，同时保留有明确审批人的紧急补丁通道。没有补丁通道的全面冻结，也可能把已知漏洞一起冻结。

第 6 至 10 天：建立系统图与风险登记表

新团队应追踪三到五条业务关键链路，从用户动作一直到数据和外部副作用，例如登录、购买、付款、文档生成或周期扣款。逐条记录入口、服务、数据存储、第三方、权限、监控、失败模式和人工恢复方式。

不要让代码审美优先于运营风险。一个能重复构建、恢复已验证的旧框架，通常比没有生产证据的重写计划更安全。

第 11 至 20 天：验证运营链路

在最安全且有代表性的环境中进行受监督测试。新团队应演示全新环境搭建、可重复构建、部署、冒烟测试、回滚、备份验证、恢复演练和事故升级。生产改动仍需遵守正常审批流程。

对于云与 SaaS 依赖，不要只凭“数据属于客户”这句话，应核实导出能力和切换义务。欧盟 Data Act 自 2025 年 9 月 12 日起适用，对云和边缘等数据处理服务的切换设定最低要求。欧盟委员会说明，供应商必须移除切换障碍，PaaS 与 SaaS 至少要提供开放接口和常用机器可读格式的导出。具体范围与例外很重要，请核对实际服务和合同。参见欧盟委员会 Data Act 说明。

如果供应商代表你处理个人数据，退出还必须符合数据处理协议。GDPR 第 28 条要求服务结束后，由控制者选择删除或返还个人数据，法律要求保留的情况除外。因此，数据清单、导出、删除证据和撤销次级处理者访问都属于接管工作。参见 EUR-Lex 上的 GDPR 正式文本。

如果产品属于 CRA 的含数字元素产品范围，需要明确切换后由谁负责网络安全风险评估、技术文档、支持期限承诺和漏洞处理。义务取决于产品和经济运营者角色。欧盟委员会 Cyber Resilience Act 摘要说明了制造商义务、漏洞处理和主要适用日期。

第 21 至 30 天：交付一个边界清晰的改动

演示文稿不能证明接管完成。选择一个会经过真实发布路径的低风险改动，例如小型缺陷、可观测性增强、依赖补丁或工作流修正。要求正常评审、自动检查、部署证据和发布后观察。

为继承的软件设置明确安全基线。NIST Secure Software Development Framework提供可融入不同开发生命周期的高层实践。对于 Web 应用，OWASP ASVS 5.0提供可测试要求，也明确支持采购场景。按风险选要求，不要因为扫描器运行一次就声称全面合规。

第 30 天应在四条路线中做决定：谨慎维护，先稳定再加功能，按边界逐步现代化，或在证据证明总成本与风险更低时替换系统。“全部重写”应当是结论，不是起始方法。

更换软件供应商可能哪里出错？

如何选择新的软件供应商？

给每位候选人同一份脱敏材料：系统图、约束、一条关键链路和目标结果。要求说明风险、未知项、访问需求、前两周计划、团队角色、决策门槛和商业假设。不要奖励最长的通用方案。

收标前先定规则。我们的默认规则是至少 70 分且没有硬性淘汰项。硬性淘汰项包括：没有实名负责人，没有安全生产访问方案，没有书面评估成果，成果权利不清，或检查前就承诺固定重写。可按产品调整权重，但不要让优秀销售演示抵消控制缺失。

Wavect 适合什么，不适合什么？

如果你有正在运行或停滞的定制软件，可以提供合法的系统与利益相关者访问，并希望在维护或开发前先做评估，Wavect 会是合适候选。我们的原则是先理解系统，记录风险，稳定关键部分，再根据证据报价后续工作。书面评估归你所有。

我们不适合盲目重写、匿名人力外包、通用 24/7 IT 服务台，或没有人能授权系统访问的接管。有时正确答案是保留当前团队并修复治理。本文由 Wavect 发布，因此评分卡代表公开声明的观点。请向每一家候选方，包括我们，索取同样证据。

可参考 FTW Ventures 案例了解我们如何说明自身贡献。若要在接管前或过程中建立独立质量基线，可查看软件 QA 服务。

软件接管常见问题