软件产品退出时，存量客户过渡可以按“退出决策与范围界定—客户分层与影响评估—过渡路径设计—通知与合同处理—迁移执行与支持—退出验收与收尾”六个阶段推进。先锁定受影响的版本、模块和客户，再按依赖程度分层，为不同客户安排升级替代、继续使用至到期、数据导出或终止服务等路径，并同步处理通知、合同、数据处置和验收。
要点总览（TL;DR）
- 软件产品退出时，存量客户过渡按“退出决策与范围界定—客户分层与影响评估—过渡路径设计—通知与合同处理—迁移执行与支持—退出验收与收尾”六个阶段推进，先锁定受影响对象再安排差异化方案。
- 范围界定要同时覆盖产品线、版本、模块和部署形态，并与合同系统、订单记录和账号体系交叉盘点客户，形成退出范围清单和包含停售、停止支持、数据保留等节点的时间表。
- 客户分层综合使用深度、集成依赖、合同期限和数据量四个维度，高依赖客户优先安排替代评估和专属迁移支持，低依赖客户以数据导出和到期终止为主，避免一刀切通知。
- 过渡路径分为升级替代、继续使用至到期、数据导出与自主迁移、终止服务与补偿四类，每条路径写明适用条件、前置动作、责任人和客户确认方式。
- 过渡完成以客户覆盖与确认率、数据处置证据、合同与账务收尾、遗留问题关闭条件和档案完整性逐项核对，未关闭的高依赖客户问题应延长支持窗口后再收尾。
退出决策先界定哪些产品、版本和客户受影响
退出决策确定后，第一项工作是把“退出什么”写清楚。范围过宽会让通知和迁移资源分散，范围过窄则容易遗漏仍在使用的模块或部署形态。范围界定要同时覆盖产品线、版本、模块和部署形态四个对象维度，再与客户清单交叉，形成可执行的退出范围清单。
操作上可按以下步骤推进：
- 列出退出对象：明确产品名称、版本号、停售与停止服务的时间点，以及是否包含特定模块、插件或本地部署形态。
- 盘点受影响客户：从合同系统、订单记录和账号体系中导出仍在有效期内的客户清单，标注合同起止日期、已购版本、部署方式和当前使用状态。
- 核对合同状态：区分已到期、自动续约、有最低服务期承诺和存在特殊条款的合同，标记需要法务提前介入的客户。
- 制定退出时间表：至少包含停售日、停止新功能发布日、停止技术支持日、数据保留截止日四个节点，并预留通知提前期和迁移窗口。
范围界定的输出物是一份退出范围清单和一张时间表。清单应能回答“哪些客户在什么时间受到什么影响”，时间表应能支撑后续通知批次和迁移批次的排期。范围清单确定后，后续分层和路径设计都以它为基准，避免执行中反复调整口径。
按依赖程度给存量客户分层
同一产品退出，对不同客户的影响差异很大。按依赖程度分层的目的，是让通知内容、支持资源和迁移优先级与客户实际风险匹配，避免对所有客户发送同一份通知、安排同一种迁移方式。
分层可综合四个维度：使用深度（活跃用户数、核心业务流程依赖程度）、集成依赖（是否通过接口与其他系统对接、是否有定制开发）、合同期限（剩余服务期长短、是否有续约承诺）、数据量（历史数据规模、导出和迁移复杂度）。每个维度给出高、中、低三档，再组合成客户分层结果。
| 分层 | 典型特征 | 过渡策略方向 |
|---|---|---|
| 高依赖客户 | 核心业务在用、有接口集成或定制、合同期较长 | 优先安排替代方案评估和迁移支持，指定专人对接 |
| 中依赖客户 | 部分流程在用、集成较少、合同期内可完成切换 | 提供标准迁移工具和批量通知，按批次推进 |
| 低依赖客户 | 使用频率低、无集成、合同临近到期 | 以数据导出和到期终止为主，减少迁移投入 |
分层表建议包含客户名称、所属分层、合同到期日、部署形态、集成情况、数据量、对接人、拟定路径和负责人等字段。分层结果直接对应后续过渡路径选择，也决定通知批次和迁移批次的先后顺序。分层完成后应组织一次跨角色评审，确认高依赖客户没有被遗漏。
设计四类过渡路径并明确适用条件
分层之后，需要为每类客户给出明确的过渡路径。常见路径有四类，选择规则应写成书面标准，让销售、客户成功和技术支持在对外沟通时口径一致。
| 过渡路径 | 适用条件 | 前置动作 |
|---|---|---|
| 升级到替代产品 | 客户有持续使用需求，替代产品能覆盖核心场景，合同期内可完成切换 | 完成功能差异评估、报价与合同变更、迁移方案确认 |
| 继续使用至合同到期 | 合同剩余期较短，客户暂无切换计划，继续使用风险可控 | 确认停止服务时间点、明确到期后不再续约、保留支持范围 |
| 数据导出与自主迁移 | 客户计划自行选择其他方案，或使用深度较低 | 约定导出格式、字段范围、交付方式和完成时间 |
| 终止服务与补偿安排 | 产品无法继续提供约定服务，或客户选择提前终止 | 法务确认终止条款、核算未履行服务对应的补偿或退款 |
路径选择应遵循先评估替代可行性、再确认客户意愿、最后落到合同动作的顺序。对高依赖客户，升级替代通常是首选，但需要先完成功能差异清单和迁移工作量评估；对低依赖客户，数据导出加到期终止往往更经济。每条路径都要写明责任人、完成时间和客户确认方式，避免路径停留在口头约定。
通知、合同与数据处置怎么安排
对外通知应与合同处理同步启动。通知分批进行：高依赖客户先由客户成功或销售一对一沟通，中低依赖客户再通过邮件或站内公告批量通知。每批通知都要写明退出对象、关键时间节点、可选路径、客户需要采取的动作和联系人，提前期根据合同约定和迁移复杂度确定，合同有明确通知期限的从其约定。
合同层面需要逐类处理：仍在服务期内的合同，确认是否变更服务范围、是否续约替代产品、是否提前终止；自动续约条款要在续约日前完成书面确认，避免被动续期；终止合同要核对未履行服务对应的退款或补偿。法务负责条款审核，销售负责客户确认，客户成功负责跟进签署进度。
数据处置要形成书面约定：导出格式（如数据库备份、CSV、标准接口文件）、导出字段范围、交付方式和期限、客户确认接收的记录，以及数据保留截止日和删除确认方式。删除完成后保留操作记录和客户确认函，作为后续审计依据。所有通知、合同变更和数据处置记录都应集中留档，便于查询和交接。
迁移执行与支持资源如何配置
迁移执行阶段的核心是把客户分层结果转化为批次计划。批次划分可参考依赖程度、合同到期时间和迁移复杂度：高依赖客户优先排期并配置专属支持，中依赖客户按合同到期先后分批推进，低依赖客户以自助导出为主。每批设定开始时间、目标完成时间和负责人。
支持资源按渠道配置：为迁移客户提供专门的支持入口，明确响应时限和升级路径。一线支持处理导出、账号和基础操作问题；涉及接口对接、数据兼容和定制开发的问题升级到技术团队；合同和补偿问题升级到法务与销售负责人。升级路径要写明触发条件和各环节责任人，避免问题在角色之间反复转交。
客户侧需要明确对接人及其职责：确认迁移范围和时间、组织内部数据核对、签署确认文件、反馈迁移中的问题。客户对接人与内部负责人之间保持固定沟通节奏，重要节点形成书面记录。迁移执行计划应包含批次表、支持渠道说明、升级路径和角色分工，作为执行和复盘依据。
角色分工与各阶段交付物
退出过渡涉及多个角色，职责不清容易造成通知口径不一致或客户问题无人跟进。建议在启动阶段就明确各角色职责和阶段交付物，并由产品负责人统一协调。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 产品负责人 | 做出退出决策，界定范围，协调各角色 | 退出范围清单、时间表、路径选择规则 |
| 客户成功 | 客户分层、一对一沟通、跟进客户确认 | 客户分层表、沟通记录、客户确认函 |
| 销售 | 合同变更、续约与终止谈判 | 合同变更或终止文件、续约记录 |
| 法务 | 审核通知文本、合同条款和补偿方案 | 通知模板、合同处理意见 |
| 技术支持 | 数据导出、迁移支持、问题处理 | 导出记录、迁移问题清单、关闭记录 |
阶段交接点要明确：范围清单确认后移交客户成功做分层；分层评审通过后移交销售和法务处理合同；迁移计划确认后移交技术支持执行；全部客户确认后由产品负责人组织验收。决策与审批归属也要写清楚，例如补偿方案由法务和财务审批，退出时间调整由产品负责人审批。
过渡计划、客户清单、迁移任务和验收记录如果分散在邮件和表格中，跨角色同步成本会很高。可以在协作工具中建立统一的项目空间，把客户分层、迁移批次、合同状态和验收项作为工作项集中跟踪，让产品、客户成功、销售和技术支持看到同一份进度。ONES 的项目与工作项管理能力可以承载这类跨角色跟踪，具体配置按团队现有流程设置。
一个中型客户的过渡示例
以下为演示情景，用于说明方法如何落地，不代表真实客户案例。
某中型制造企业使用该软件产品三年，活跃用户约八十人，通过接口与内部报表系统对接，合同剩余十个月，历史数据量较大。按分层维度评估，该客户属于高依赖客户：核心业务流程在用、存在接口集成、合同期较长、数据量高。
分层结论确定后，客户成功与客户对接人召开一次过渡沟通会，说明退出时间表和可选路径。客户选择升级到替代产品，双方确认功能差异清单和迁移范围，销售同步发起合同变更，法务审核新合同条款。技术支持安排专属迁移窗口，先完成接口适配验证，再分批导出历史数据并导入替代产品，客户对接人负责内部数据核对和用户培训安排。
完成标志包括：新合同签署生效、历史数据导出并导入完成且客户确认、接口切换验证通过、客户对接人书面确认迁移完成、原产品账号按约定时间停用。该客户的全部记录归入过渡档案，作为验收依据。
退出过渡的完成检查
过渡是否收尾，可以按以下清单逐项核对，每项都要有可查证的记录，不能只凭口头确认。
- 客户覆盖与确认率：受影响客户清单中的每个客户都有对应的过渡路径和沟通记录，高依赖客户确认率达到约定目标，未确认客户有跟进计划和责任人。
- 数据处置完成证据：已完成导出的客户有交付记录和客户接收确认；约定删除的数据有删除操作记录和确认文件；保留期限内的数据存放位置明确。
- 合同与账务收尾：合同变更、终止和续约文件签署完毕，退款或补偿按审批结果执行，账务系统中相关合同状态已更新。
- 遗留问题与关闭条件：迁移问题清单中的未关闭项逐条标注责任人和预计完成时间，明确哪些问题必须在停止服务前关闭，哪些可以转入常规支持流程。
- 档案完整性：通知记录、客户确认、合同文件、数据处置记录和验收结论集中归档，便于后续查询和审计。
全部检查项通过后，由产品负责人确认退出过渡完成，并将遗留事项移交对应责任人持续跟进。若存在未关闭的高依赖客户问题，应延长支持窗口或调整停止服务时间，待问题关闭后再完成收尾。
常见问题
合同里没有约定退出通知期限，提前多久通知客户比较合适？
合同没有明确约定时，提前期可按迁移复杂度倒推：需要升级替代或接口适配的高依赖客户，通常要预留功能评估、合同变更、数据迁移和内部培训的时间，通知应早于停止服务日数月发出；使用深度低、以数据导出为主的客户，提前期可以短一些，但仍要覆盖客户内部审批和数据核对的周期。
无论提前期长短，通知中都要写明停售日、停止支持日、数据保留截止日三个节点，并保留客户签收或回复记录。若合同存在自动续约条款，通知还应早于续约确认日，避免客户被动续期。
客户希望继续使用到合同到期，但合同剩余时间较长，怎么处理？
继续使用至合同到期适用于剩余服务期较短、客户暂无切换计划且继续使用风险可控的情况。剩余时间较长时，需要先确认两件事：产品在该期间能否维持约定的服务水平和安全更新，以及到期后客户是否有可行的后续安排。
可行的做法是与客户书面确认继续使用的支持范围、停止服务时间点和到期后不再续约的安排，同时提前启动数据导出或替代方案评估。若产品无法维持约定服务，应转入终止服务与补偿路径，由法务核对未履行服务对应的退款或补偿，不宜以继续使用名义拖延处置。
客户数据导出后，原系统中的数据要保留多久、怎么确认删除？
数据保留期限应在通知和合同处理文件中写明，并与退出时间表的数据保留截止日保持一致。保留期内要明确数据存放位置和访问权限，避免无人管理。
导出交付时，记录导出格式、字段范围、交付方式和客户接收确认。到达保留截止日后执行删除，保留删除操作记录，并取得客户对删除完成的书面确认。导出记录、接收确认、删除记录和确认函集中归档，作为后续审计和客户问询的依据。
迁移过程中客户提出的接口兼容问题迟迟无法关闭，是否要推迟停止服务？
是否推迟取决于问题对客户核心业务的影响程度。若问题导致客户关键流程无法在新方案中运行，且属于高依赖客户，应延长支持窗口或调整停止服务时间，待问题关闭后再完成收尾；若问题只影响非核心场景，可以转入常规支持流程，标注责任人和预计完成时间，同时按原计划推进其他收尾动作。
判断标准应写入迁移问题清单，明确哪些问题必须在停止服务前关闭、哪些可以转常规支持。调整停止服务时间由产品负责人审批，并同步更新通知和合同相关记录。
过渡计划涉及产品、客户成功、销售、法务和技术支持，怎样让各方看到同一份进度？
常见做法是在启动阶段确定统一的项目空间，把客户分层、迁移批次、合同状态和验收项作为工作项集中管理，各角色按职责更新状态，产品负责人按阶段组织评审和交接。这样通知口径、客户确认和迁移进度都基于同一份记录，减少邮件和表格反复核对。
ONES 的项目与工作项管理能力可以承载这类跨角色跟踪，具体字段、状态和权限按团队现有流程配置。工具之外仍需明确阶段交接点和审批归属，例如补偿方案由法务和财务审批，退出时间调整由产品负责人审批。
