替换 Jira 时，原插件能力不能按“插件好不好用”来取舍，而要看它承载的业务动作是否仍在支撑当前流程、审计要求和数据连续性。凡是卡住流程流转、留下合规记录、承担跨系统数据交换或支撑历史追溯的能力，应优先保留并由目标平台承接；只服务个人便利、界面美化或低频统计的能力可以放弃。ONES 可作为承接载体之一，具体取舍仍需逐项盘点与试点验证。
要点总览（TL;DR）
- 按能力而非按插件做取舍：把每个在用插件拆成能力项，逐条判断是否仍支撑当前业务流程、审计要求和数据连续性。
- 必须保留的能力有四类：流程卡点与审批门禁、合规留痕与审计追溯、跨系统数据交换与同步、历史数据可查询与可追溯。
- 可放弃的能力通常只服务个人便利、界面美化或低频统计；仍需要但实现方式可换的能力，用目标平台原生功能、通用报表工具或外部工具承接。
- 完成判断需要插件使用数据、业务方与管理员共同参与，并在目标平台测试环境验证承接效果；关键卡点无方案、合规要求未确认、历史数据迁移未验证时应暂缓或缩小范围。
- 用试点对照保留清单逐项验证，记录放弃能力的实际影响，三条判定标准同时满足后再推进全量迁移。
先给结论：按能力而非按插件做取舍
插件只是能力的载体。同一个插件里，可能既有审批门禁这类关键动作，也有批量编辑、颜色标记这类便利功能。按插件整体决定去留，容易把关键能力连同边角功能一起丢掉，也容易为了保留一个小功能而背上整套插件的迁移成本。更稳妥的做法是把每个在用插件拆成若干条“能力项”，逐条判断它在当前业务中还承担什么作用。
据此可以把原插件能力分成三类：
| 类别 | 判断特征 | 处理方式 |
|---|---|---|
| 必须保留 | 承担流程卡点、合规留痕、跨系统数据交换或历史数据可追溯 | 在目标平台找到原生承接或等效配置，验证通过后才切换 |
| 可替代承接 | 能力本身仍需要，但实现方式可以换 | 用目标平台原生功能、通用报表工具或外部工具承接，接受体验差异 |
| 可放弃 | 只服务个人便利、界面美化、低频统计，或已无人使用 | 直接放弃，记录影响，不再投入迁移成本 |
这条主线的判断依据是业务流程、审计要求和数据连续性，插件本身的评价只作为参考。一个插件即使团队评价很高，如果它承载的动作已经不在当前流程中，也不构成保留理由；反过来，一个使用人数不多的插件，只要它是某个审批节点的唯一入口，就必须认真对待。
插件能力为什么会影响替换决策
Jira 插件通常以几种方式嵌入研发流程：在状态流转上增加校验或审批门禁，在字段层面做必填、格式或联动校验，把工作项数据汇总成跨项目报表，与代码仓库、CI、IM 或客服系统做双向同步，以及扩展权限模型实现按角色或按项目的细粒度控制。这些能力一旦缺失，影响往往不在界面上，而在流程的实际运行中。
能力断层的后果可以从两个维度看。交付节奏上，原本自动流转的审批变成人工催办，原本自动同步的缺陷状态需要手工回填，团队会在切换后一段时间内明显感到阻力。数据连续性上，历史工作项里的自定义字段、审批记录、关联关系如果无法带过去，后续追溯问题来源、复盘交付过程就会缺少依据。这两类影响都不会在切换当天全部暴露，往往在第一个迭代结束或第一次审计时才显现。
因此价值判断要回到业务对象和角色动作：这个能力作用在哪个工作项类型上，由哪个角色触发，产生什么记录，下游谁在消费这个结果。把这几问答清楚，能力是否关键自然清楚，而不是停留在“这个插件大家用得多不多”。
哪些能力必须保留：四类硬性条件
满足以下任一条件的能力，应列入必须保留清单，并在目标平台完成承接验证后再安排切换。
流程卡点与审批门禁
判断问题：这个能力是否决定了某个工作项能否进入下一状态？如果去掉它，是否会出现未经评审就上线、未经确认就关闭的情况？典型场景包括上线前审批、需求变更评审、缺陷关闭前的验证确认。这类能力是流程的闸门，缺失会直接改变流程的实际执行方式。
合规留痕与审计追溯
判断问题：这个能力产生的记录是否被内部审计、外部认证或行业监管要求保留？记录能否被导出、被查询、被关联到具体的人和时点？审批意见、操作日志、评审签字这类内容，即使使用频率不高，也不能在迁移中丢失。
跨系统数据交换与同步
判断问题：这个能力是否在 Jira 与其他系统之间传递数据？传递是单向还是双向？中断后哪一方的数据会失真？代码提交关联、测试结果回写、客服工单同步都属于这一类。需要确认目标平台是否具备等效的集成方式，以及同步规则能否重新配置。
历史数据可查询与可追溯
判断问题：历史工作项中的自定义字段、状态变更记录、附件和评论，迁移后是否还能按原样查询？跨项目的关联关系是否保留？研发过程连续性依赖这些数据，迁移方案需要明确覆盖项目、工作项、状态、字段、流程、附件和历史记录的范围。
| 硬性条件 | 核心判断问题 | 未承接的后果 |
|---|---|---|
| 流程卡点与审批门禁 | 是否决定工作项能否流转到下一状态 | 流程实际执行方式被改变 |
| 合规留痕与审计追溯 | 记录是否被审计或监管要求保留 | 审计时缺少依据 |
| 跨系统数据交换 | 是否在系统间传递数据、中断后哪方失真 | 数据不一致，需人工回填 |
| 历史数据可追溯 | 历史字段、记录、关联是否可查询 | 复盘与追溯缺少依据 |
哪些能力可以放弃或换方式承接
与硬性条件相对，以下特征的能力通常可以放弃，或换一种更轻的方式承接。
- 个人便利型能力：批量编辑、快捷操作、个人看板定制、键盘快捷键增强。这类能力提升的是个体操作速度，缺失后团队仍能完成工作，只是多几步操作。可以在切换后观察实际抱怨程度，再决定是否补充。
- 界面增强型能力：主题美化、字段颜色标记、卡片样式调整。这类能力不影响数据和流程，放弃后对业务结果没有实质影响。
- 低频统计能力：使用频率很低的报表插件，或只在小范围周期性使用的统计视图。可以先确认目标平台的原生报表能否覆盖主要指标，剩余部分用通用报表工具或导出后处理承接。
- 可由目标平台原生能力承接的能力：例如原本靠插件实现的状态校验、字段联动、通知规则，如果目标平台的工作流配置和自动化规则本身支持，就不需要再寻找同类插件。
- 可由外部工具或手工流程临时承接的能力：切换初期尚未配置好的辅助功能，可以用表格登记、定时人工检查等方式过渡，但需要设定过渡期限，避免临时方案长期化。
放弃不等于忽略。每一项决定放弃的能力，都应记录它当前的使用者、使用频率和放弃后的替代动作，便于试点阶段观察实际影响。对于仍需要但换方式承接的能力，要明确承接方是谁、配置由谁完成、验收标准是什么。
投入与前提：做这项判断需要准备什么
完成一次可信的能力盘点，需要数据、人员和时间的共同投入，缺一项都容易得出片面结论。
- 插件清单与使用情况数据：导出当前安装的插件列表，结合使用日志、工作项字段引用情况、自动化规则调用情况，判断每个插件是否仍被实际使用。仅凭管理员印象容易高估或低估使用频率。
- 业务方与管理员共同参与：管理员了解配置和集成关系，业务方了解流程实际怎么走。两边对照，才能识别出“配置还在但流程已不用”和“配置不起眼但卡着关键节点”两类情况。
- 盘点与验证的时间投入：盘点本身可以按插件数量安排，通常需要逐项访谈和记录；承接验证需要在目标平台的测试环境中实际配置并跑通代表性流程，这部分时间取决于保留清单的长度和流程复杂度。
- 目标平台能力核验的前提：对每项拟保留能力，需要确认目标平台是否存在原生承接方式，或需要通过流程自动化、开放接口做二次配置。核验结论应记录为迁移前提，而不是留到切换时再发现缺口。
在承接环节，ONES 提供项目、Wiki、测试用例、流程自动化和开放能力等基础能力，可用于匹配常用插件场景；对于企业已有的定制场景，迁移前仍需逐项评估，不能假设所有插件都能一一对应。数据迁移方面，ONES 的 Jira 迁移覆盖项目、工作项、状态、字段、流程、附件和历史记录，并包含问题类型、工作流、字段配置、权限配置等系统配置以及用户和用户组，这些范围可以作为核对历史数据可追溯能力的参照。
什么情况下应暂缓替换或缩小范围
出现以下情况时，建议暂缓整体切换，或先把替换范围缩小到不受影响的项目和团队。
- 关键流程卡点没有承接方案：某个审批门禁在目标平台找不到等效配置，且短期内无法通过自动化规则实现。此时强行切换会直接改变流程执行方式。
- 合规留痕要求尚未确认：审计或监管部门对记录保留的形式、期限、可导出性有明确要求，而目标平台的记录方式尚未经过确认。这类问题应在切换前与合规方对齐。
- 历史数据迁移方案未验证：自定义字段、状态历史、附件和跨项目关联的迁移结果没有在测试环境验证过。数据连续性无法确认时，切换后追溯成本会显著上升。
- 高频集成依赖尚未打通：与代码仓库、CI、测试管理或客服系统的高频同步仍未在目标平台跑通。集成中断会同时影响两边的数据质量。
缩小范围是一种务实的过渡方式：先选择插件依赖较少、流程相对标准的团队切换，把保留清单中的能力在真实使用中验证一遍，再逐步扩大范围。比较稳妥的路径是把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配。
用试点验证保留与放弃的判断
盘点得出的结论需要通过试点检验，重点不是验证工具能不能用，而是验证保留清单是否真的被承接、放弃清单是否真的没有造成阻塞。
- 选取代表性团队与流程：选择覆盖主要工作项类型、包含至少一个审批门禁和一个跨系统集成的团队，避免只选流程最简单的团队，否则验证不出真实问题。
- 对照保留清单逐项验证：在目标平台中实际走一遍每个保留能力对应的流程，确认触发条件、记录结果和下游消费都符合预期。每项记录“已承接”“部分承接”“未承接”三种状态。
- 记录放弃能力的实际影响：观察试点团队在缺少这些能力后，是否出现额外的沟通成本、手工操作或数据补录。影响超出预期的能力，重新评估是否应转入保留清单。
- 根据结果调整迁移范围：对“未承接”的保留能力，要么补充配置方案，要么将该流程所在团队排除在本轮切换之外；对影响可控的放弃能力，确认放弃决定并归档记录。
试点的判定标准可以归纳为三条：保留清单中的能力全部有明确的承接状态；放弃清单中的能力没有造成流程阻塞或数据缺失；试点团队能够在切换后按原有节奏完成一个完整迭代。三条同时满足，再推进全量迁移；任一条件不满足，先解决对应缺口，而不是靠延长过渡期掩盖问题。
常见问题
插件使用人数很少，是否就可以直接放弃？
不能仅凭使用人数判断。使用频率低但承担审批门禁、合规留痕或跨系统同步的能力，仍应列入必须保留清单。更可靠的判断方式是看这个能力作用在哪个工作项类型上、由哪个角色触发、产生什么记录、下游谁在消费结果。使用人数少但卡着关键节点的能力，和用得多但只服务个人便利的能力，处理方式正好相反。
目标平台没有对应插件时，原插件能力还能怎么承接？
常见承接方式有三种：一是用目标平台原生的工作流配置、字段校验和自动化规则实现等效控制；二是把报表类需求转到通用报表工具或导出后处理；三是切换初期用表格登记、定时人工检查等方式过渡，但需要设定过渡期限。对每项拟保留能力，应先在测试环境确认承接方式是否可行，再决定是否切换。ONES 提供项目、Wiki、测试用例、流程自动化和开放能力等基础能力，可用于匹配常用插件场景，企业已有的定制场景仍需逐项评估。
历史工作项里的自定义字段和审批记录，迁移时如何确认不丢失？
先把迁移范围写清楚，再在测试环境验证。需要覆盖项目、工作项、状态、字段、流程、附件和历史记录，系统配置方面包括问题类型、工作流、字段配置、权限配置，以及用户和用户组。验证时抽取包含自定义字段、状态变更记录和跨项目关联的样本工作项，逐项核对迁移后的查询结果。ONES 的 Jira 迁移覆盖上述范围，可作为核对历史数据可追溯能力的参照。
试点验证要跑多久、达到什么状态才算通过？
试点时长取决于流程复杂度，通常以试点团队完成一个完整迭代为观察周期。判定标准可以归纳为三条：保留清单中的能力全部有明确的承接状态（已承接、部分承接或未承接）；放弃清单中的能力没有造成流程阻塞或数据缺失；试点团队能在切换后按原有节奏完成一个完整迭代。三条同时满足再推进全量迁移，任一条件不满足，先解决对应缺口。
部分团队流程特殊，能否先切换其他团队、特殊团队暂缓？
可以，缩小范围是常见的过渡方式。先选择插件依赖较少、流程相对标准的团队切换，把保留清单中的能力在真实使用中验证一遍，再逐步扩大范围。对存在关键流程卡点无承接方案、合规留痕要求未确认、历史数据迁移未验证或高频集成未打通的团队，排除在本轮切换之外更稳妥。比较稳妥的路径是把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配。
