针对成熟且有众多客户的saas系统，当我们对某个功能模块进行全面升级，发现该模块架构落后，想要迭代就要整体重构，但是该功能线上又同时有众多客户在运行，这种情况我们该如何重构这个功能且又能保障线上正在使用的客户不收影响。

本文将分享实际工作经验的思考和沉淀，仅供参考，期望能对你有所帮助~

一、客户分层分析

1、增量客户：新客户使用系统，该能力直接变更为新版，这个决策基本上没有疑问。

2、存量客户：存量商户又区分 已使用功能和未使用功能客户

• 已使用功能：需要拉取目前已使用客户数据，客户体量，使用深度，等数据后在做进一步分析和决策。
• 未使用功能：还要区分一部分是知道未使用，一部分是不知道未使用，在功能SOP以及前后线信息传达上要做一定考虑。

通过客户分层的分析，不难看出我们功能迁移聚焦在存量商户上，当然不同功能体量不同的数据表现也会有不同的切换方案，下面将介绍两种常见的方案处理，大家更多参考分析过程实操需要根据实际情况而定。

二、前置准备工作

1、新旧版对比SOP：用于协同方知晓背景和优势（要有链路思考往往这种重构对前线伙伴和客户沟通会产生很多解释成本，所以这个要前置思考）

• 撰写为什么要做重构，重要和紧急维度进行阐述，核心表达出背景让协同方更多是传达至一线了解原因，因为一线距离市场最近。
• 明确新版功能相较于旧版有什么优势体验，流程，功能等等，以及不迭代缺失的功能以及未来的方向定位。（以上两点可以在项目启动文档中完成）
• 上线切换方案：不论是哪种方案的选择都要在该文档中呈现给到一线进行解释（该方案会在下面说明）

2、存量数据提取：提取存量已使用客户的占比体量，使用深度，以及是否还有待完善的需求，根据这些数据决定下一步的收敛方案。

3、一线功能调研：

• 直面客户沟通调研：针对提取存量客户的数据，了解其使用功能体验，重构是否有想法，对我们定位是否认可，等等
• 一线伙伴调研：在他们针对客户实施过程中是否有卡点，槽点，重构覆盖内容是否有遗漏，新版本功能一线伙伴如何理解，是否有诉求等等。

三、存量收敛方案

常见收敛方案有两种：核心区别是存量收敛的力度

方案一、保留两套功能运行：该方案决策前提是数据使用很高，功能差异较大，切换成本较高无法实现稳定切换过度保留一套功能。这种方案适用于较大模块重构升级。

这套方案核心是客户自行收敛，没有做过多动作推动，实际情况无推动客户是很难主动升级的，这就像ios版本升级一下，现在已经ios18，但是依然有大量ios16及以下版本在运行。

当然也会做很多引导，比如存量功能移到至新版，存量不升级等等。

方案二、保留一套功能运行：该方案决策前提是使用数据可控，功能升级亮点较多，切换引导成本可控。这种方案适用于中小模块的重构升级同时很考验产品的精准刀法。

针对存量正在使用的客户，需要分阶段进行引导收敛，基本上分为以下几个阶段：从告知到关闭增量再到进行能力下线。

• 功能告知引导：使用旧版本弹窗告知新旧功能，一线口径统一至新版等等引导告知要明确。
• 关闭存量增量数据：针对旧版本功能无法进行新建，但是可以使用查看正在进行中的能力。
• 明确下线节点：功能与xxx节点进行下线强制使用新版能力
• 预留兜底方案：实际过程中可能会存在我们无法预料的情况，所以兜底方案要预留。

这套方案要关注数据变化，做好数据埋点，因为动作是明确的但是节奏需要看实际情况而定，并不是说我们自己明确几个月还是几周完成，而是以实际情况确定，防止自嗨。

以上两种方案是切换的思路思考，可能还有其他更好的方案，思考可以不仅局限于此。

四、功能上线节奏

不同的方案上线节奏有所不同：

方案一：上线节奏可以正常放量也可以分节奏放量影响不大，毕竟是新增能力。

方案二：上线节奏也需要做做精准的计划，因为保留一套就要看客户实际反馈情况，短时间内全量某个小的功能有问题就会导致非常的被动。

针对影响面较广、评估不明确、产生用户较大行为路径改变等需求，需进行逐步稳定放量。

• 针对客户分层逐步放量：前期提取常用商户部分放量观测是否有问题反馈，这里就是前期试水校验能力是否有问题，要从里面挑选部分深度部分体量中等，进行混合放量观测情况。
• 逐步等比例放量：上述无问题反馈开始进入等比例放量，剔除周五以及节假日按照比例进行持续推进观察功能反馈情况。
• 大客户全量：大客最后全量，针对大客需要前期沟通和告知，接受后部分大客精准上线符合诉求后再全部上线。

这种放量节奏可控，当中途出现问题时可以及时停止并不救缩短影响范围。

最后说下，如果大家在实际工作中遇到这类情况，很荣幸这是一件难而正确的事情，希望在工作中能稳定心态也希望本文对你有所帮助~