CRM二次开发后如何升级：改动盘点、业务验收与回退安排

CRM二次开发后，升级不应直接覆盖生产系统。更稳妥的做法是：先确认定制改了什么，再按目标版本要求完成适配，在独立测试环境验证客户、商机和权限流程，最后安排正式切换与失败恢复。能否升级、需要多少工作，不能只凭“支持版本升级”判断，还要看当前定制内容和双方约定的维护范围。

对于使用淘销宝客户和商机模块、权限配置的企业，升级验收可以围绕一条具体业务链展开：销售找到自己的客户，继续推进关联商机，主管按授权查看团队进展，无关人员不能访问受限资料。技术人员负责适配和部署，业务负责人负责确认这条流程仍然成立；两者都通过，才具备上线条件。

先判断：这次升级会碰到哪些定制

企业负责人不必亲自阅读代码，但需要让实施方说清楚：改动在哪里、为什么改、影响谁、由谁维护。不要只接受“做过一些个性化开发”这样的描述。

下面的分类用于整理改动，不代表所有CRM采用相同的扩展机制，也不能直接推导升级工作量。

左右滑动查看完整表格

改动记录不完整，不等于永远不能升级，但应先补齐盘点，再评估排期。尤其是已经直接修改核心代码或数据库结构的系统，不宜跳过差异分析就承诺上线时间。

如果使用的是开源CRM，应由维护人员核对目标版本的官方升级说明、依赖要求及相关许可证条件。这里需要确认的是本次升级路径，而不是重新做一遍开源产品选型。

用一份改动台账，把升级责任落实到人

升级容易卡住的地方，往往不是有没有安装包，而是没有人能说明某项定制为什么存在，或者没有人负责判断它是否仍然需要。

建议由企业指定一名升级负责人，协调业务、开发和运维。小团队可以由同一人承担多个角色，但每项工作都应有明确的责任人。

改动台账至少记录以下内容：

• 业务用途：解决什么问题，哪些岗位实际使用，是否仍然保留。
• 改动位置：涉及哪个模块、字段、规则、代码或数据结构。
• 版本基线：当前运行版本、定制代码对应版本、计划升级的目标版本。
• 业务依赖：影响哪些客户记录、商机处理和角色权限。
• 责任与验收：谁负责适配，谁确认结果，用什么操作证明通过。

例如，“调整了商机流程”不够具体。应进一步写清：哪个阶段的进入条件发生变化，哪些岗位可以修改，已有商机升级后应停留在哪个阶段。这样才能把技术改动转化为可以检查的业务结果。

按五个步骤完成二次开发后的升级

以下步骤适用于需要保留既有定制的CRM升级项目，是建议的实施流程，不代表系统会自动完成这些工作。

1. 确定升级范围与路径。 技术负责人列出当前版本、目标版本、保留的定制和暂不调整的业务流程，依据对应版本说明确认是否需要分阶段升级。企业负责人同时明确本次升级目的，避免把升级与新增大批需求混在一起。
2. 准备独立测试环境与恢复材料。 运维人员按实际部署方式准备可用于恢复的应用、数据库、配置和相关文件备份，并验证恢复过程。测试所用客户数据应按企业要求脱敏或限制访问，不能为测试而扩大资料可见范围。
3. 先适配定制，再验证数据变化。 开发人员处理代码、扩展和数据结构的差异，记录每项调整。涉及字段转换时，应明确旧字段与新字段的对应关系、空值处理方式，以及无法转换的记录由谁处理，不能默默丢弃异常数据。
4. 让业务人员执行核心流程验收。 销售代表完成客户查找、商机查看和业务更新；主管检查管理范围；系统管理员检查授权边界。不能只由开发人员确认页面能够打开，也不能只核对升级前后的记录总数。
5. 按约定窗口正式切换并复查。 上线前确认暂停写入的范围、最终备份、执行顺序、失败恢复条件和通知对象。上线后重复关键业务操作，并观察是否出现记录缺失、归属变化、权限异常或业务无法继续推进等情况。

正式切换前，应把未解决问题分成“阻断上线”和“可安排后续处理”两类。客户与商机关联错误、受限资料被越权访问、关键数据无法恢复，应作为阻断项处理，而不是上线后再观察。

淘销宝场景：怎样验证客户、商机和权限没有被改坏

下面是一个假设示例，不代表真实客户案例，也不代表所有版本都默认包含示例中的定制字段和规则。

一家企业在CRM中按自身业务调整了商机阶段，并约定销售只处理授权范围内的客户。现在需要升级，同时保留原有业务规则。对采用淘销宝相关方案的企业，可以以客户和商机模块、权限配置及版本升级范围为讨论基础，由实施方确认具体适配方式。

先固定字段含义，再核对业务关系

企业可由销售主管与实施方共同选取具有代表性的测试记录。建议覆盖客户编号、客户负责人、商机编号、关联客户、商机阶段等信息；这些是验收字段示例，实际名称和可用范围应以交付配置为准。

检查时既要比较字段值，也要比较关系。例如，商机仍然存在，但关联到了另一位客户，不能算升级成功；客户负责人没有变化，但负责人已经无法查看该客户，也不能算通过。

左右滑动查看完整表格

应同时覆盖正常记录和边界情况，例如已关闭商机、负责人变更后的客户，以及只有特定角色可见的记录。具体覆盖范围由企业的实际定制决定，不需要为了测试而加入无关功能。

区分系统能力与人工验收

淘销宝的客户和商机模块用于承载相关业务记录，权限配置用于落实访问范围；具体版本升级与定制适配应按交付方案确认。制定测试样本、判断业务含义是否正确、批准正式上线，仍然是企业与实施人员的工作，不能把这些动作理解为系统自动验收。

完成后应能观察到的结果是：销售继续处理原有客户和商机，主管能够查看授权范围内的信息，无关人员不能越权访问。这些是本次升级的验收目标，不是未经验证的效果承诺。

相关业务范围可查看客户管理说明；涉及既有定制或私有化环境时，应结合软件定制与私有化说明确认实施边界。不能仅凭某项标准能力存在，就推断企业现有定制可直接升级。

升级失败时，怎样避免回退反而丢数据

回退不能只理解为重新安装旧版程序。若新版已经修改数据结构，或者上线后产生了新的业务记录，就需要同时考虑应用、数据库、配置和新增数据的处理方式。

企业负责人应在上线前要求实施方回答三个问题：

• 什么时候停止继续升级？ 明确哪些故障触发恢复决定，以及谁有权决定停止。
• 恢复到哪个时点？ 明确备份对应的业务时间点，并评估企业能够接受的数据和业务中断范围。
• 切换期间的新记录怎么办？ 明确如何识别、保留和补录，避免直接恢复旧备份覆盖新增业务。

如果暂时没有可靠办法处理切换期间的新数据，可以评估在约定窗口暂停相关写入，并准备人工记录方式。具体选择取决于业务连续性要求和部署条件，不应默认任何方案都支持不停机升级。

企业负责人如何决定是否放行

是否上线，建议以证据而不是口头保证判断：定制改动有对应处理结果，测试环境通过了客户、商机和权限验收，恢复方案经过验证，未解决问题有明确责任人和处理安排。

升级预算也不宜只看安装费用。可以按定制梳理、差异适配、数据处理、业务测试、上线保障及后续维护分别估算，再与升级目的比较。如果维护责任尚未明确，应先补齐责任安排，而不是把“支持升级”当作所有定制都会持续兼容的保证。

对需要持续保留客户与商机流程、同时明确权限和维护责任的企业，淘销宝可以围绕这些具体需求讨论配置与定制方案。下一步不必先增加功能，而是带着当前版本信息、定制改动台账和一条核心业务验收流程，与实施方确认升级路径、交付范围及后续维护责任。