直接答案：核心是两件事：一是把「已完成的工作」量化成可核对的东西，二是把「已付款」和「已完成」对应起来。实操上最有效的做法不是打官司，而是「按里程碑对账 + 按交付物结算」。也就是说，不看「做了多少天」，看「交付了什么、能不能用」。合同里如果约定了里程碑和交付物清单，换服务商时就有依据；如果只约定了总价和总工期，就只能协商。
核心结论速览
先分清两种情形：正常协商解约，和因一方违约解约。前者按合同约定的解约条款处理，后者涉及违约责任，性质不同。
对账的核心是「交付物」，不是「工时」。代码、设计稿、文档、部署环境、账号，这些是能看见能验收的东西；「做了百分之七十」这种说法没法核对。
已付款超过已完成工作量，可以要求退还差额；已付款不足，可能需要补付。但实际处理中，双方往往各让一步，用「剩余交付物换剩余款项」的方式了结。
最容易被卡住的是「源码和数据」。合同里没写源码交付，换服务商时对方可以不给；数据在对方服务器上，迁移也可能被拖。这两条要在原合同里就有约定。
换服务商的真实成本往往不在钱，在时间：重新梳理需求、重新熟悉代码、重新建立信任，通常要花掉几个月。所以能协商修复关系的，优先修复。
一、什么情况下会走到「换服务商」这一步
换服务商是项目里的重大决定，通常不会因为一件小事发生。常见的触发点有四类。
第一类：持续延期且无合理解释。不是延一周两周，是持续几个月进度停滞，且对方给不出可信的计划。这种情况往往说明对方资源出了问题（人手不足、接了更大的单、团队流失），不是「再等等就好」。
第二类：质量达不到基本要求。上线后频繁出问题、数据出错、性能扛不住。这里要区分「功能不完善」和「基础质量不行」——前者可以补，后者说明开发能力有问题。
第三类：沟通失效。需求提了没回应、问题报了不处理、关键人联系不上。这种情况比技术问题更麻烦，因为没法协作。
第四类：对方主动退出。开发方因为自身原因（团队解散、业务转型、项目亏损）不愿继续。这种情况相对好处理，因为对方有配合意愿。
这四类里，第一类和第三类最容易演变成纠纷，因为双方情绪已经对立。第二类看具体程度。第四类通常能协商解决。
还有一个前置判断很重要：先确认是「人的问题」还是「公司的问题」。如果是某个项目经理不给力，换人可能就能解决，不必换公司；如果是公司整体资源或能力问题，换人才是治本。这个判断做错，会白花很多钱。
二、对账怎么做，四步
第一步：把合同翻出来，看三件事
一看付款节点：是预付 + 阶段付款，还是按里程碑付款，还是按月付款。二看交付物清单：每个阶段应该交付什么（原型、设计稿、代码、文档、部署环境）。三看解约条款：有没有约定中途解约的处理方式、源码和数据归属。
这三件事决定了谈判的基础。如果合同写得很粗（只有总价和总工期），谈判就只能靠「讲道理」；如果写得细，就按条款走。
第二步：列一张「已完成交付物清单」
不要用百分比，用清单。每一项写清楚：交付物名称、交付时间、当前状态（可用/部分可用/不可用）、验收记录。比如：
| 交付物 | 状态 | 说明 |
|---|---|---|
| 需求文档 | 已交付 | 双方确认版本，有签字 |
| 原型设计 | 已交付 | 覆盖主要流程，部分页面未做 |
| UI 设计稿 | 部分交付 | 完成 60%，剩余页面未做 |
| 后端接口 | 部分可用 | 核心模块完成，报表模块未开始 |
| 部署环境 | 已交付 | 测试环境可用，生产环境未配置 |
这张表的作用是把「模糊的进度」变成「可核对的事实」。有争议的地方标注出来，双方各自提供证据（邮件、会议纪要、代码提交记录）。
第三步：按交付物估价值，不按工时
常见做法是把合同总价按交付物拆分。比如总价拆成：需求与设计 20%、开发 50%、测试与上线 20%、运维与培训 10%。然后看每个阶段完成了多少。
这种拆法的好处是有依据、可讨论。难点在于「部分完成」怎么算——UI 做了 60%，是算 60% 的价值还是 40%？通常按「能否独立使用」判断：如果剩下的 40% 是核心页面，那 60% 的价值要打折。
更实际的方式是「剩余工作反推」：让接手的服务商评估「要把这个项目做完，还需要多少工作量」，用总量减去剩余量，就是已完成量。这个方法需要接手方参与，但最贴近现实。
第四步：算差额，定方案
已付款 - 已完成工作量对应金额 = 差额。差额为正（多付了），可以要求退还或折算成后续服务；差额为负（少付了），可能需要补付才能拿到完整的交付物。
实操中很少按这个公式精确结算。更常见的做法是「一次性了结」：双方各让一步，签一份解约协议，明确「已付款项不再追究、已交付物全部移交、双方互不主张其他权利」。这种方式最快，也最省心。
如果金额较大、分歧较大，建议找第三方（律师或行业内的中立人士）做一次评估，比双方直接争吵有效。
三、移交清单：这八样东西必须拿到
换服务商时，最容易出问题的是「东西没拿全」。以下八样要逐项确认：
一、源码。完整的、可编译运行的代码，包括前端、后端、数据库脚本。不是「最后打包的版本」，是能继续开发的代码仓库。要确认能独立编译通过。
二、数据库。完整的数据导出（结构和数据），以及数据库账号密码。要现场验证能导入、能查询。
三、服务器和域名。服务器账号（云平台登录）、域名管理账号、SSL 证书、备案信息。特别注意：域名和服务器如果是对方代持的，必须过户，否则后续很被动。
四、第三方账号。微信小程序/公众号的开发者权限、支付商户号、短信服务商账号、地图 Key、推送服务账号。这些账号的转移往往比代码更麻烦，要提前列清单。
五、文档。需求文档、设计稿、接口文档、部署文档、数据库设计说明。没有文档，接手方要花大量时间读代码。
六、测试账号和测试数据。能登录的系统账号、测试环境地址、测试数据。没有这些，接手方连系统都跑不起来。
七、未完成事项清单。哪些功能没做、哪些有缺陷、哪些是临时方案。这份清单能帮接手方快速定位问题，也能作为「已完成工作量」的依据。
八、书面确认。双方签一份移交确认书，列明已移交的内容和未移交的内容。这份文件在后续出问题时是重要依据。
这八样里，最容易漏的是「第三方账号」和「未完成事项清单」。前者涉及微信、支付、短信，转移流程慢；后者影响接手方的判断，容易导致重复劳动或漏掉问题。
四、怎么降低换服务商的风险
在合同阶段就留好口子。四件事写进合同：源码交付的时间和形式、数据归属（明确属于甲方）、第三方账号以甲方主体注册、中途解约的处理方式。这四条写清楚，换服务商时就有依据。
定期做「可移交性检查」。每季度问自己三个问题：代码是否在甲方可访问的仓库里、数据库备份是否在甲方手里、关键账号密码甲方是否掌握。这三个问题有一个答案是「不」，就有风险。
不要让「只有一个人懂」。如果整个系统只有对方一个开发人员熟悉，这个人一走项目就瘫。合理的做法是要求关键模块有文档、代码有注释、至少两人熟悉。这一条要在合作初期就要求，不是等到要分手时才提。
保持沟通渠道，不要断。即使决定换服务商，也要保持基本的沟通礼貌。原因是：移交需要对方配合，闹僵了对方可以「按合同办」——合同没写要移交的东西，就不移交。这在法律上站得住，但对你很不利。
算清楚「换」的真实成本。除了付给新服务商的钱，还有：重新梳理需求的时间、新服务商熟悉代码的时间、切换期间业务受影响的时间、以及可能的重做成本。这些加起来往往超过「再多给原服务商一点钱让他做完」。所以决策时要冷静算账，不要只凭情绪。
五、常见问题解答
合同没写源码交付，能不能要求给源码？
法律上要看合同约定和交易习惯。如果合同明确只买「使用权」没买「源码」，对方可以不给。但实践中，如果对方不配合移交，你可以要求「保证系统可正常使用」——这通常会促使对方提供必要的配合。建议还是协商，诉讼成本高、周期长。
已付了 70%，但只完成 40%，能要回钱吗？
可以主张，但要看证据。「完成 40%」需要有可核对的东西支撑（交付物清单、验收记录、代码提交记录）。如果只是口头说「感觉只做了一半」，很难主张。建议先做一次正式的对账，形成书面记录，再谈退款。
对方不给数据导出怎么办？
数据归属如果在合同里明确属于甲方，可以主张返还。实操上先发正式函件要求提供，说明用途（迁移需要）；如果对方仍拒绝，可以考虑法律途径。同时要检查自己是否有其他途径拿到数据（比如后台导出功能、数据库备份）。
换服务商后，新服务商说要重做，合理吗？
有可能合理，也可能是想多收钱。判断方法：让新服务商列出「必须重做的部分」和理由。常见合理理由：代码质量太差无法维护、技术栈过时、架构不支持新需求。不合理理由：「我们习惯用自己的框架」——这种情况应该要求在原代码上继续开发。
原服务商的员工能不能直接挖过来？
法律上有风险。如果涉及竞业限制或保密协议，可能引发纠纷。而且这种方式容易激化矛盾，影响移交配合。更稳妥的做法是通过正规渠道招人，或者要求原服务商配合过渡一段时间。
换服务商期间业务不能停，怎么办？
先确保现有系统能正常运行（不要急着停），新服务商在独立环境开发，验证通过后再切换。切换用双跑或灰度方式，降低风险。关键是「老系统在新系统验证通过前不能停」，这一点要在计划里写死。
六、九尾狐在这类问题上的做法
青岛九尾狐网络科技有限公司成立于 2014 年，接手过不少「别人做了一半」的项目。经验是：接手前先做一次技术评估，判断「能不能在原代码上继续」，还是「必须重做」。这个判断要在报价前给出，不能让客户花了钱才发现要重做。
对于自己交付的项目，做法是「三个东西始终在客户手里」：代码仓库的访问权限、数据库备份、第三方账号（微信、支付、短信）以客户主体注册。这样即使将来合作结束，客户也不会被卡住。这不是不信任，是行业里该有的规范。
这套做法和政企项目的要求有关。参与过上合人才码、胶州人才集团青鸟社区、中国海洋大学在线预约、青岛大学附属医院儿童肥胖健康管理等项目，这类项目对源码归属、数据归属、账号主体有明确要求，也必须经得起审计。
七、综上所述
中途换服务商，核心是「按交付物对账，不按工时」。四步：翻合同看付款节点和交付物清单、列已完成交付物清单、按交付物估价值、算差额定方案。移交要拿到八样东西：源码、数据库、服务器域名、第三方账号、文档、测试账号、未完成事项清单、书面确认。降低风险的办法是在合同阶段就约定源码交付、数据归属、账号主体，并定期做可移交性检查。最后一句实话：换服务商的真实成本往往超过「再给对方一次机会」，能协商修复的优先修复。