原插件能力缺失时，迁移的对象是插件承载的工作流行为与扩展点，插件本身只是这些行为的载体。本文按“盘点—映射—试迁移—核验—回退”的准备阶段展开，帮助团队把“能力缺失”拆成可执行清单。ONES 可在工作项、状态流转与评审记录上承接部分常用插件场景，具体对应关系需逐项评估。
要点总览（TL;DR）
- 迁移对象是插件承载的触发、动作、通知、字段联动与外部调用，先按五类行为盘点，再逐条映射到目标平台机制。
- 映射时优先用原生工作流与自动化规则承接，其次用开放接口对接外部服务，最后才评估人工步骤；无法承接的行为需在流程调整、外部替代、接受降级中选定一种并取得业务确认。
- 用一条覆盖行为类型最多的代表性工作流做试迁移，逐条比对触发、动作结果、通知对象与字段变化，保留操作记录、通知截图和字段前后对比作为核验证据。
- 回退预案在试迁移前确定：保留原插件可恢复的时间窗口，以审批断链、通知丢失、外部调用失败作为回退触发条件；核心行为无法等价实现且业务不接受降级时停止推进。
- 历史记录与附件的批量搬运、目标平台上线后的日常配置治理不在本文范围，分别交由数据迁移与平台配置治理工作承接。
来源目标与范围：插件缺失后要迁移什么
迁移工作的第一步是把“插件不能用了”翻译成一份可核对的边界。范围表需要同时写清三件事：源插件是什么、它替团队做了哪些事、目标平台准备用什么机制接住这些事。范围一旦模糊，后续映射就会把数据搬运、日常配置等不同性质的工作混进来，导致责任人和验收标准都说不清。
源侧信息建议记录到可追溯的粒度：插件名称与版本、使用团队、依赖入口（菜单入口、工作项面板、看板按钮、Webhook 回调等）。版本信息尤其重要，同一插件的不同版本在触发条件和字段联动上可能有差异，按实际运行版本盘点才能避免遗漏。
插件承载的行为清单按五类拆解：触发条件（状态变更、字段赋值、定时、手动点击）、自动动作（改状态、写字段、建子任务、分配处理人）、通知（站内信、邮件、群机器人）、字段联动（计算字段、必填联动、选项过滤）、外部调用（调用第三方接口、同步外部系统）。每一类都对应目标平台上不同的承接方式，拆得越细，映射阶段越容易判断可行性。
目标侧需要写明平台与版本，以及原生机制可覆盖的范围，例如内置工作流状态机、自动化规则、开放接口和集成能力。这里只界定“有哪些机制可用”，具体怎么映射留到执行阶段。
范围表还应明确排除项。历史记录与附件的批量搬运属于研发数据迁移与映射的工作，目标平台上线后的日常配置与治理属于研发平台业务配置与治理的工作，两者都不在本阶段的迁移清单内。把它们单独列出，可以避免准备阶段被数据量估算和权限梳理拖住。
| 范围表字段 | 填写内容 | 示例（演示情景） |
|---|---|---|
| 源插件 | 名称、版本、使用团队、依赖入口 | 某状态联动插件 v2.x，研发一部，工作项详情面板 |
| 行为清单 | 触发、动作、通知、字段联动、外部调用 | 状态变为“待测试”时自动指派测试负责人并发送群通知 |
| 目标平台 | 平台与版本、可用原生机制 | 目标平台工作流与自动化规则、开放接口 |
| 纳入项 | 本阶段要迁移的行为 | 状态联动指派、通知 |
| 排除项 | 交由其他工作承接的内容 | 历史附件搬运、上线后日常配置治理 |
本阶段输入及依赖：迁移前需要备齐的材料
准备阶段最常见的返工原因是信息不全就开工：映射做到一半发现密钥归属不清，或者试迁移时找不到原插件的配置截图。建议在动手前把输入分成四组，逐项确认责任人和到位状态。
配置与凭证类。插件配置导出文件或完整截图、自定义脚本、Webhook 地址、密钥与账号归属。密钥要确认由谁持有、能否在目标平台复用、是否需要重新申请。外部调用的目标地址和鉴权方式应一并记录，否则替代实现无法验证连通性。
影响面类。受影响的工作流、项目、团队与角色清单。同一插件行为可能被多个项目复用，按项目列出使用情况，可以判断试迁移选哪条流程最有代表性，也能估算切换时的沟通范围。
目标平台确认类。目标平台的权限模型、扩展接口与集成能力确认结果。需要确认的事项包括：自动化规则能覆盖哪些触发条件、开放接口的调用方式与限制、外部系统集成是否已有现成通道。这些确认结果直接决定映射阶段哪些行为可以原生承接、哪些需要替代方案。
业务约定类。业务方对行为变更的接受范围与时间窗口。通知渠道变化、字段计算方式调整、审批节点增减，都属于业务可感知的变化，需要提前取得确认。时间窗口则决定试迁移和回退预案的排期。
| 输入项 | 到位标准 | 责任人 |
|---|---|---|
| 插件配置导出或截图 | 覆盖全部在用行为，可对照核对 | 插件管理员 |
| 脚本与 Webhook 地址 | 可读取、可确认调用目标 | 插件维护人 |
| 密钥与账号归属 | 明确持有人与复用方式 | 系统管理员 |
| 受影响工作流与团队清单 | 按项目列全，标注使用频率 | 项目经理 |
| 目标平台能力确认结果 | 权限、接口、集成逐项有结论 | 平台管理员 |
| 行为变更接受范围 | 业务方书面确认 | 业务负责人 |
执行与映射方法：把插件行为逐条落到目标机制
映射的基本单位是一条插件行为，而不是一个插件。把每条行为按“触发—条件—动作—通知”四段拆开，再分别寻找目标平台的承接机制，可以避免“整体搬不过去”的笼统判断。拆解后常见的情况是：触发和动作能原生承接，通知渠道需要调整，外部调用需要替代服务。
承接方式大致分四类。原生工作流承接状态流转与审批节点；自动化规则承接条件判断与自动动作；开放接口承接与外部系统的数据交换；人工步骤承接暂时无法自动化的环节。映射时优先使用原生机制，其次考虑开放接口，最后才评估人工步骤，因为人工步骤会改变团队的操作习惯，需要业务方明确接受。
对于无法直接承接的行为，有三种处置路径，每种都需要业务方确认后才能写入方案：
- 流程调整。改变触发方式或动作顺序，让行为落在目标平台已有机制内。例如把“字段变更即触发”改为“进入特定状态时触发”，需要确认业务上是否可接受。
- 外部服务替代。用独立脚本或集成服务承接原插件的外部调用，目标平台通过开放接口与之交互。需要确认接口调用限制、失败重试方式和运维责任归属。
- 接受能力降级。明确放弃部分自动化，改为人工操作或降低通知频率。降级项要写进方案并告知受影响团队，避免上线后被当作缺陷。
映射表建议包含五个字段：原行为、目标实现方式、负责人、验证方式、风险。验证方式要具体到可执行的检查动作，例如“在测试项目触发一次状态变更，确认处理人被指派且通知送达指定群”。风险栏记录依赖条件，例如“依赖外部接口可用性”“通知渠道变更需业务确认”。
| 原行为（演示情景） | 目标实现方式 | 负责人 | 验证方式 | 风险 |
|---|---|---|---|---|
| 状态变为“待测试”自动指派测试负责人 | 目标平台工作流后置动作 | 平台管理员 | 测试项目触发一次，核对处理人字段 | 多项目复用同一流程时需逐项目确认 |
| 指派后发送群通知 | 自动化规则调用群机器人 | 平台管理员 | 检查通知对象与内容格式 | 通知渠道变更需业务确认 |
| 调用外部系统同步缺陷编号 | 开放接口加外部服务 | 集成负责人 | 发起一次同步，核对返回结果 | 接口调用限制与失败重试待确认 |
| 按字段组合计算优先级 | 人工步骤或字段默认值 | 项目经理 | 抽查十条工作项比对结果 | 属能力降级，需业务方接受 |
在目标平台上，这些行为最终会落到具体的工作项类型、状态流转和自动化规则上。ONES 的流程自动化与开放能力可用于承接常用插件场景，例如状态联动、通知和外部调用；迁移前仍需按上表逐项评估，不能假设所有插件行为都能一一对应。映射结果确认后，工作项的状态流转和评审记录可以在 ONES Project 中统一管理，便于后续核验时对照操作记录。
试迁移与核验：用小范围验证行为等价
映射表写完不等于方案可行，需要用一条代表性工作流做试迁移，取得可判断通过与否的证据。代表性工作流的选取标准是：覆盖的行为类型最多、涉及角色较全、业务影响可控。通常选一条包含状态流转、自动指派、通知和一次外部调用的流程，能在较小范围内暴露大部分差异。
试迁移按以下步骤推进：
- 在目标平台的测试项目或隔离环境中配置映射后的工作流与自动化规则。
- 准备一组测试工作项，覆盖正常路径和边界情况，例如字段为空、多人同时操作、外部接口超时。
- 逐条执行原行为对应的操作，记录触发是否发生、动作结果是否符合预期、通知对象是否正确、字段变化是否符合映射表。
- 把结果与插件运行时的表现逐项比对，差异项单独登记。
差异项要判定性质：属于配置问题的，修正配置后重新验证；属于能力缺口的，回到映射表调整处置路径，或提交业务方决定是否接受降级。两类问题混在一起记录，会导致后续无法判断迁移是否真正完成。
核验证据建议保留三类：操作记录（谁在什么时间触发了什么）、通知截图（接收对象、内容、渠道）、字段前后对比（变更前后的值）。证据按行为条目归档，与映射表一一对应，评审时可以直接对照。试迁移通过的标准是：纳入范围的行为全部有验证记录，差异项均有明确结论和责任人。
回退与停止条件：什么情况下暂停或退回
回退预案要在试迁移开始前确定，而不是等问题出现再讨论。核心是保留原插件或旧流程可恢复的时间窗口：在试迁移和切换期间，原插件保持可用状态，旧流程的配置不做删除，确认新方案稳定后再按计划下线。时间窗口的长度取决于业务节奏和试迁移覆盖范围，需要与业务方共同确认。
触发回退的条件应写成可观察的现象，便于当班人员判断：
- 关键审批断链：审批节点未按预期流转，工作项停留在错误状态。
- 通知丢失：应发送的通知未送达指定对象，或发送到错误渠道。
- 外部调用失败：与外部系统的同步持续失败，且重试无法恢复。
停止推进的条件与回退不同。回退是暂时恢复旧流程，停止推进是判定当前方案不成立：核心行为无法等价实现，且业务方不接受降级方案。此时应暂停迁移，把差异项和评估结论整理成文档，重新讨论替代实现或调整业务预期，而不是在试迁移中反复修补。
| 判定项 | 回退 | 停止推进 |
|---|---|---|
| 触发情形 | 审批断链、通知丢失、外部调用失败 | 核心行为无法等价实现且业务不接受降级 |
| 动作 | 恢复原插件或旧流程，保留现场记录 | 暂停迁移，整理差异与评估结论 |
| 后续要求 | 记录触发时间、影响范围、恢复耗时，复盘原因 | 重新讨论替代方案或调整业务预期后再启动 |
每次回退都要留下记录：触发条件、影响的工作项与团队、恢复动作和耗时、根因判断。复盘时区分是配置疏漏、能力缺口还是业务预期偏差，结论回写到映射表和核验记录中。回退记录积累起来，也是判断能否进入正式切换的依据。
常见问题
插件行为在目标平台只能部分承接时，怎么判断该调整流程还是接受降级？
先看这条行为在业务链条中的位置。如果它只影响操作便利性，例如通知频率或字段默认值，调整流程或接受降级通常可以推进；如果它处在关键审批或交付节点上，例如状态流转后的自动指派，就需要业务方确认变更后的操作方式是否可接受。
判断时把三个问题写进映射表：调整后的触发条件是否仍能覆盖原场景、人工步骤增加后由谁执行、降级项是否会被误认为缺陷。三项都有明确答案再定方案，避免试迁移阶段反复返工。
原插件的 Webhook 和密钥还能继续用吗？
需要逐项确认，不能默认沿用。Webhook 地址取决于目标平台是否提供对应的回调机制，地址格式和鉴权方式可能变化；密钥则涉及持有人、有效期和目标平台能否安全存储。
准备阶段把外部调用的目标地址、鉴权方式和密钥归属记录清楚，试迁移时实际发起一次调用验证连通性。若目标平台通过开放接口与外部服务交互，还需确认调用限制和失败重试方式，这些结论写入映射表的风险栏。
试迁移要跑多久、覆盖多少条工作流才算够？
覆盖范围以行为类型为准，不以工作流数量为准。选一条同时包含状态流转、自动指派、通知和一次外部调用的流程，通常能暴露大部分差异；如果团队有多套差异较大的流程，再补一条边界情况较多的流程。
通过标准是纳入范围的行为全部有验证记录，差异项均有明确结论和责任人。时间长度取决于外部接口联调和业务方确认的节奏，建议在回退时间窗口内完成，避免新旧流程长期并行造成操作混乱。
回退之后，之前试迁移产生的配置和数据怎么处理？
回退时保留现场记录，包括触发时间、影响的工作项与团队、恢复动作和耗时。试迁移期间在目标平台产生的测试工作项和配置，按项目约定清理或隔离，避免与正式数据混淆。
复盘结论要回写到映射表和核验记录：区分是配置疏漏、能力缺口还是业务预期偏差。同一类问题反复触发回退时，说明当前映射方案不成立，应转入停止推进的评估，而不是继续在试迁移中修补。
团队同时使用多个插件，应该一次全部迁移还是分批推进？
建议按行为类型分批，而不是按插件逐个搬。先把所有插件的触发、动作、通知、字段联动和外部调用汇总成一张总清单，再按承接难度排序：原生机制可直接覆盖的先迁移，需要外部服务替代或涉及业务降级的后迁移。
分批推进时，每批都走完映射、试迁移、核验的完整流程，并共用同一套回退预案。这样单批出问题时影响范围可控，回退记录也能为后续批次提供参照。
