插件能力迁移的对象是插件承载的业务行为，包括触发条件、执行动作和输出结果，插件安装包本身不在迁移范围内。本文按盘点、分类、重建验证、灰度切换四步展开，说明每步的输入、动作、交付物和完成标志，并给出角色分工与检查清单。记录数据的搬运与字段映射属于数据迁移，目标平台的日常配置属于平台治理，本文只讨论行为与能力的迁移。
要点总览（TL;DR）
- 插件能力迁移的对象是插件承载的业务行为——触发条件、执行动作、输出结果，安装包本身随旧平台退役，不进入迁移范围。
- 盘点以行为为单位拆行，记录触发时机、涉及对象、调用方、使用频率和依赖关系；高频且多项目共用的行为优先，低频但涉及发布卡点、合规等关键环节的行为单独标出。
- 分类按可替代、需重建、可放弃三类判定，可替代要求触发条件、执行动作、输出结果三项对齐，任何一项对不上就归入需重建或标记待验证。
- 重建先做高频关键行为，用抽样触发、结果比对、异常分支检查做新旧对照，三项等价才算通过；能力未确认时标记待验证，不写成已支持。
- 切换按重要度分批灰度，预先写清回退条件（行为不一致、通知缺失、流程阻塞），完成检查清单逐项通过并确认旧插件下线后才算迁移结束。
插件能力迁移先回答哪三个问题
动手之前先明确三件事，后面的工作才有统一口径：迁移什么、怎么分类、什么算完成。这三个问题决定了盘点表的字段设计、处置决策的依据，以及最终验收的标准。
第一个问题：迁移什么。旧平台上的插件往往同时包含安装包、配置项和业务行为。安装包随旧平台一起退役，配置项中与记录数据相关的部分归数据迁移处理，真正需要搬到新平台的是插件被使用时产生的行为——什么条件下触发、执行了什么动作、产出了什么结果、通知了谁。以行为为迁移单位，才能判断新平台上是否已经具备等价能力。
第二个问题：怎么分类。旧插件数量多、价值差异大，全部按重建处理会浪费开发资源，全部按放弃处理会丢失关键流程。需要一套判定规则，把每个行为归入可替代、需重建、可放弃三类，并明确每类的负责人。
第三个问题：什么算完成。完成的标准是每个已盘点行为都有明确结论——已在新平台验证通过、已确认放弃并有记录、或已标记待验证并有人跟进。旧插件下线确认是最后一步，没有这一步，迁移只能算部分完成。
四步框架的输入、动作、输出与完成标志如下表，可作为整个迁移工作的总览。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步 盘点 | 旧平台插件清单、使用记录、维护人信息 | 逐插件拆解为行为条目，记录触发时机、涉及对象、调用方、使用频率和依赖关系 | 插件行为盘点表 | 清单内每个插件都已拆成至少一条行为记录，字段填写完整 |
| 第二步 分类 | 插件行为盘点表 | 按判定规则归入可替代、需重建、可放弃，指定负责人并预估工作量 | 分类处置决策表 | 每条行为都有分类结论、负责人和排期 |
| 第三步 重建与验证 | 分类处置决策表、新平台能力清单 | 用原生能力、自动化规则或接口重建关键行为，逐条做新旧对照验证 | 新旧行为对照验证记录 | 关键行为验证通过，未通过项有处理结论 |
| 第四步 切换 | 验证记录、回退方案 | 按重要度分批灰度切换，观察期内跟踪遗留项，确认旧插件下线 | 切换记录与完成检查表 | 检查清单逐项通过，旧插件下线确认 |
需要区分的是：旧平台的项目、工作项、状态、字段、附件和历史记录等数据搬运，属于数据迁移与映射的工作，有独立的工具和校验方式；新平台上工作流、字段配置、权限的日常调整，属于平台业务配置与治理。插件行为迁移会用到这两项工作的成果——比如重建行为时需要知道新平台的工作项类型和状态定义——但本身不承担数据搬运和日常配置的职责。
第一步：盘点插件清单并标注行为与依赖
盘点的目标是把“我们装了哪些插件”转换成“哪些业务行为依赖插件”。前者是一张安装列表，后者才能支撑分类判断。盘点不要求一次穷尽所有细节，但要求每条记录都能回答：这个行为在什么条件下发生、做了什么、影响了谁。
建议的盘点表字段如下，每个插件按行为拆行填写，一个插件承载多个行为时拆成多行。
| 字段 | 填写说明 |
|---|---|
| 插件名称与版本 | 旧平台上的插件标识，便于回溯和联系维护人 |
| 承载动作 | 用一句话描述插件替用户做了什么，如“工作项进入待验证状态时自动通知测试负责人” |
| 触发时机 | 事件触发、定时触发还是人工点击；写明具体事件或时间条件 |
| 涉及对象 | 行为读写的工作项类型、文档、流水线、通知渠道等 |
| 调用方 | 哪些团队、项目或角色在使用；是全员默认启用还是个别项目自行安装 |
| 使用频率 | 近三个月触发次数或使用人数，用于区分高频关键与低频长尾 |
| 依赖关系 | 该行为依赖的其他插件、脚本、外部系统接口，以及是否有下游行为依赖它的输出 |
| 维护人 | 插件原作者、内部维护人或已无人维护 |
区分高频关键与低频长尾，建议同时看两个维度：触发频率和使用范围。高频且多项目共用的行为，迁移优先级最高；低频但涉及合规、发布卡点等关键环节的行为，即使触发次数少也要单独标出，不能因为频率低就归入长尾。使用频率数据可以从旧平台的操作日志、通知记录或插件自身的统计中获取，取不到精确数据时由使用方负责人估算并注明估算依据。
依赖关系是盘点中最容易被忽略的部分。插件与工作项状态流转、文档模板、流水线步骤、通知渠道之间的关联，决定了重建时的先后顺序：被依赖的行为要先重建，否则下游行为无法验证。建议在盘点表中增加一列“下游依赖”，记录哪些行为依赖本条目的输出，形成一张简单的关系图。
盘点产出物是完整的插件行为盘点表，由研发效能负责人牵头组织，插件维护人负责填写自己维护的条目，业务使用方确认使用频率和关键性判断。完成标志是清单内每个插件都已拆解为行为条目，且每条都有维护人和使用方确认。
第二步：按可替代、需重建、可放弃分类处置
分类的目的是把有限的重建资源集中到真正需要开发的行为上。三类判定标准如下，判定时以行为为单位，同一个插件的不同行为可以归入不同类别。
| 类别 | 判定条件 | 典型情形 | 处置方式 | 负责人 | 工作量预估 |
|---|---|---|---|---|---|
| 可替代 | 新平台原生能力或自动化规则可直接覆盖，触发条件、执行动作、输出结果三项均能对应 | 状态变更通知、字段联动赋值、简单的定时提醒 | 在新平台配置对应规则，纳入验证清单 | 平台管理员 | 配置级，按条估算 |
| 需重建 | 依赖外部接口、脚本或定制逻辑，新平台无直接对应能力，需要开发与联调 | 与外部系统双向同步、复杂计算后回写字段、自定义报表导出 | 基于开放接口或脚本重建，安排开发排期和联调环境 | 插件维护人或开发负责人 | 开发级，按接口数量和联调轮次估算 |
| 可放弃 | 低频且无关键环节依赖，或业务已下线、无人认领 | 试用期安装后未使用的插件、已停止业务线的辅助工具 | 记录放弃理由和确认人，不安排重建 | 业务使用方确认，效能负责人归档 | 无开发工作量 |
判定时容易出现的偏差是把“功能看起来相似”当成可替代。可替代的判断标准是三项对齐：触发条件一致、执行动作等价、输出结果满足下游使用。任何一项对不上，就应归入需重建或标记待验证，不能凭印象归为可替代。
排期方式建议按类别区分：可替代项由平台管理员集中配置，按批次推进，不占用开发资源；需重建项进入开发排期，按依赖关系排序，被依赖的行为优先；可放弃项只需完成确认和归档，在切换前完成记录即可。每类的负责人和预估工作量填入分类处置决策表，作为后续进度跟踪的依据。完成标志是盘点表中每条行为都有分类结论、负责人和排期，没有悬空条目。
第三步：在新平台重建关键行为并做对照验证
重建的顺序是先高频关键、再长尾。高频关键行为影响多数团队的日常协作，优先重建并验证，可以尽早暴露平台能力缺口；长尾行为在关键行为稳定后批量处理，避免前期被大量低价值条目拖慢节奏。
重建的做法取决于分类结果。可替代项在新平台上配置原生规则或自动化流程，配置时逐项对照盘点表中的触发时机、涉及对象和输出结果；需重建项通过开放接口或脚本实现，开发前先确认接口的调用方式、频率限制和异常处理方式，联调时用测试数据跑通正常分支和异常分支。
验证口径是新旧行为等价，判断依据是三项对照：触发条件是否在相同事件下发生、执行动作是否产生相同效果、输出结果是否满足下游使用。三项都对齐才算验证通过，功能近似但输出格式或通知对象不同的，按未通过处理。验证记录建议用下表格式，每条行为一行。
| 行为编号 | 旧平台触发条件 | 新平台触发条件 | 旧执行动作 | 新执行动作 | 输出结果比对 | 异常分支检查 | 结论 |
|---|---|---|---|---|---|---|---|
| 示例：B-01 | 工作项状态变为待验证 | 同左 | 通知测试负责人 | 同左 | 通知对象、内容一致 | 负责人空缺时的处理已确认 | 通过 |
验证方式包括抽样触发、结果比对和异常分支检查。抽样触发选取有代表性的工作项或文档，实际走一遍流程；结果比对检查通知对象、字段值、生成内容是否与旧平台一致；异常分支检查覆盖负责人空缺、对象被删除、接口超时等情形，确认新配置在这些情况下有合理处理。
遇到新平台能力尚未确认的情况，在验证记录中标记为待验证，写明需要确认的具体问题和跟进人，在确认前不写成已支持。资料未提及某项能力时，同样按待验证处理，不据此推断平台缺少该能力。完成标志是关键行为全部验证通过，未通过项和待验证项都有明确处理结论和责任人。
在行为重建环节，ONES 的方案思路是用标准能力和开放平台替代常用插件，结合 ONES Project、Wiki、TestCase、流程自动化和开放能力承接常用插件场景。对于原来依赖插件的功能，ONES 建议先梳理实际使用的插件，再通过上述能力做功能匹配；企业已有的定制场景在迁移前仍需逐项评估，不能假设所有插件都能一一对应。这与本文“先盘点行为、再逐项匹配”的做法一致，具体某个插件能否对应、流程自动化的配置细节和限制，需要在评估阶段逐项确认。
角色分工与各阶段交付物
迁移涉及四类角色，职责按阶段划分，每个交付物对应到具体的人，避免出现“大家都参与、没人负责”的情况。
| 角色 | 盘点阶段 | 分类阶段 | 重建验证阶段 | 切换阶段 |
|---|---|---|---|---|
| 研发效能负责人 | 组织盘点、确定清单范围和时间盒 | 主持分类评审、裁定争议条目 | 跟踪重建进度、协调资源 | 决定切换批次和回退 |
| 插件原作者或维护人 | 填写自己维护插件的行为条目和依赖关系 | 提供技术判断，参与需重建项的评估 | 负责重建开发与联调 | 支持切换期问题排查 |
| 平台管理员 | 提供旧平台插件安装和使用数据 | 判断可替代项，确认新平台配置方式 | 配置原生规则、执行验证 | 执行切换操作、监控运行状态 |
| 业务使用方 | 确认使用频率和关键性 | 确认可放弃项，提出关键环节要求 | 参与抽样验证，确认结果可用 | 在观察期内反馈问题 |
交付物与评审节点对应如下：盘点表完成后由效能负责人组织一次盘点评审，确认清单覆盖完整；分类处置决策表完成后进行分批评审，争议条目由效能负责人裁定；对照验证记录在每批重建完成后评审，业务使用方签字确认关键行为可用；切换前进行切换方案评审，确认批次顺序和回退条件。所有评审记录与交付物存放在同一位置，便于交接和追溯。
交接主要发生在插件维护人变更或外部维护人退出的场景。交接时移交该插件的行为条目、依赖关系说明和重建状态，接收人确认后更新盘点表中的维护人字段。评审和交接的记录方式保持一致，用同一份表格追加状态和日期，不另建文档。
示例：一个提交触发通知插件的迁移过程
以下为演示情景，用于说明流程如何落地，不代表任何真实企业的迁移结果。
旧平台上的插件行为是：开发人员提交代码后，插件读取提交信息中的工作项编号，将对应工作项状态从“开发中”改为“待验证”，并通知该工作项的测试负责人。依赖对象包括代码仓库的提交事件、工作项状态字段和通知渠道；调用方为三个研发团队，近三个月日均触发约四十次；维护人为平台组一名工程师。
分类判断：该行为的触发条件是代码提交事件，执行动作是状态变更加通知，输出结果是测试负责人收到提醒。新平台具备代码提交关联工作项和状态自动流转的配置能力，三项可以对齐，归入可替代，由平台管理员配置，预估为配置级工作量。若提交信息格式不规范导致无法识别工作项编号，这一异常分支需要在配置时单独确认处理方式。
重建配置要点：在新平台设置自动化规则，触发条件为代码提交且提交信息包含有效工作项编号；执行动作为将工作项状态更新为待验证；输出动作为向测试负责人发送通知。配置时保留旧插件的编号识别规则，确保历史提交习惯不受影响。
验证结果：抽样选取十个工作项实际提交，状态变更和通知对象均与旧平台一致；异常分支测试中，提交信息缺少编号时规则不触发并记录日志，与旧插件行为一致。遗留问题是通知文案模板需要业务方确认措辞，标记为待确认，由业务使用方在切换前反馈。该行为验证通过后进入切换批次。
切换顺序、回退条件与完成检查
切换按插件重要度和使用范围分批进行。第一批切换高频关键行为，覆盖多数团队的日常流程，观察期最短但监控最密；第二批切换低频但涉及关键环节的行为，逐项确认后再放开；第三批处理长尾行为和可放弃项的归档。每批切换前确认该批行为的验证记录完整，切换后保留旧插件一段时间作为并行期，确认无异常后再下线。
回退条件需要提前写清楚，触发任一条件即回退到旧插件或上一批状态：行为结果与验证记录不一致，如状态未变更或变更错误；通知缺失或通知对象错误，影响测试、发布等环节的响应；流程阻塞，如工作项无法流转、提交无法关联；异常分支处理失效，产生错误数据。回退由效能负责人决定，平台管理员执行，回退后记录原因并重新验证。
完成检查清单如下，逐项核对通过才算迁移完成：
- 盘点表覆盖旧平台全部在用插件，每个插件已拆解为行为条目
- 每条行为都有分类结论、负责人和排期，无悬空条目
- 关键行为在新平台验证通过，验证记录有业务使用方确认
- 待验证项和遗留问题有跟进人和处理期限
- 可放弃项已记录放弃理由和确认人
- 各批切换完成，观察期内无触发回退条件的问题
- 旧插件下线确认，维护人知悉并停止相关维护工作
迁移后设置观察期，高频关键行为建议观察两到四周，长尾行为可缩短。观察期内跟踪遗留项清单，每周更新状态，遗留项全部关闭或转为常规需求后，迁移工作正式结束。观察期发现的新问题按回退条件判断是否需要回退，不需要回退的纳入遗留项继续跟踪。
常见问题
插件迁移时，旧插件里的配置项要不要一起搬？
按配置项的性质分开处理。与记录数据相关的配置，例如字段映射、状态对照，随数据迁移与映射的工作一起处理；与行为相关的配置，例如触发条件、通知对象、执行动作，属于本文讨论的插件能力迁移范围，需要在新平台上重新配置并验证。安装包本身不迁移，旧平台下线时一并退役。
实际操作中两类工作会交叉：重建行为时需要知道新平台的工作项类型和状态定义，这些来自数据迁移与平台配置的成果。建议在盘点阶段就标注每个配置项归属哪类工作，避免两边重复处理或遗漏。
新平台上找不到对应能力的插件，是直接放弃还是先开发？
先判断这个行为是否仍在支撑当前业务。如果业务已下线、无人认领，或近三个月几乎没有触发且不涉及关键环节，可以归入可放弃，记录放弃理由和确认人即可。如果行为仍在关键流程中，即使触发频率低，也应归入需重建，通过开放接口或脚本实现，并安排开发和联调排期。
还有一种情况是新平台能力尚未确认。这时在验证记录中标记待验证，写明需要确认的具体问题和跟进人，确认前不写成已支持，也不据此推断平台缺少该能力。待验证项要有处理期限，不能长期悬空。
验证时发现新平台行为“差不多但不完全一样”，算通过吗？
按三项对照判断：触发条件是否在相同事件下发生、执行动作是否产生相同效果、输出结果是否满足下游使用。三项都对齐才算通过。功能近似但通知对象不同、输出格式不同、异常分支处理不同的，按未通过处理，回到重建环节调整。
如果差异来自业务方主动提出的改进需求，例如通知文案调整，可以记录为遗留项，由业务使用方确认后单独处理，不与迁移验证混在一起。示例中的通知文案待确认就属于这一类。
灰度切换期间旧插件要不要立即停用？
建议保留一段并行期。每批行为在新平台验证通过后切换，旧插件暂时保留，确认观察期内没有触发回退条件的问题后再下线。并行期长短按行为重要度区分：高频关键行为建议观察两到四周，长尾行为可以缩短。
并行期需要明确以哪边为准，避免同一行为在新旧平台各触发一次造成重复通知或状态冲突。通常的做法是切换后以新平台为准，旧插件只作为回退手段，不主动触发。
迁移完成后，观察期发现的问题怎么处理？
先按回退条件判断：行为结果与验证记录不一致、通知缺失或对象错误、流程阻塞、异常分支处理失效，触发任一条件即回退，由效能负责人决定、平台管理员执行，回退后记录原因并重新验证。不触发回退条件的问题纳入遗留项清单，每周更新状态。
遗留项全部关闭或转为常规需求后，迁移工作正式结束。观察期内新增的问题如果属于原有业务的新需求，不再计入本次迁移范围，按常规需求流程处理。
