Jira工作流迁移时，条件分支和权限规则需要拆解后重建，不能按界面形态直接照搬。做法是先把Jira中的判断条件、跳转路径、执行人和权限持有者拆成可核对的对象，再按目标系统的状态机、角色模型和字段条件逐条映射，最后用覆盖各分支的样例工单做试迁移验证。本文给出范围界定、映射表结构和核验记录方式。
要点总览（TL;DR）
- 条件分支和权限规则不能按Jira界面形态照搬，先把判断条件、跳转路径、执行人和权限持有者拆成可核对对象，再按目标系统的状态机、角色模型和字段条件逐条重建。
- 条件分支按判断对象分四类推进：字段值、用户或角色、子任务或关联问题状态、权限前置；转换条件与校验分开记录，无法等价表达时采用合并分支、人工校验或拆分工作流等降级方案。
- 权限映射按项目级、问题类型级、状态级、字段级、转换级五层拆开核对，Jira项目角色与用户组对应到目标系统角色或用户组，权限放宽与收紧逐条记录并交业务方确认。
- 用覆盖每个条件分支、每个权限边界和典型角色的样例工单做试迁移，核验转换触发、无权拦截、字段编辑和受限可见性，保留操作记录或截图形成核验记录表。
- 关键分支无法表达且降级方案不被接受、出现越权或核心角色无法完成流转时，暂停配置写入并回退到上一版本，Jira原配置在切换完成前保持可查。
迁移范围：哪些条件分支和权限规则要迁
迁移开始前先划定边界，避免把Jira中多年积累的全部配置一次性搬走。范围清单按四层展开：工作流清单、状态与转换清单、条件与权限清单、明确排除项。每一层都标注所属项目和问题类型，因为同一个Jira实例中不同项目往往复用不同工作流方案。
纳入迁移的对象包括：正在使用的活跃工作流及其状态、转换；转换上挂载的条件、校验和后处理动作；与这些工作流绑定的权限方案、项目角色、用户组和问题安全级别。历史工单中已经走完的流转记录属于数据迁移范畴，与规则映射分开处理，但状态名称和历史状态的对应关系要在本阶段一并确认。
排除项需要写清楚：Jira日常操作教程、与替换目标无关的通用数据迁移技术、替换目标尚未确定时的工具选型比较，都不在本阶段范围内。停用多年、仅作存档的工作流可以列入“不迁移”清单，但要注明保留查询方式，防止后续审计时找不到依据。
范围清单建议包含以下字段，作为后续映射的工作底稿：
| 清单项 | 记录内容 | 确认人 |
|---|---|---|
| 工作流清单 | 工作流名称、所属项目、问题类型、是否活跃 | 项目管理员 |
| 状态与转换清单 | 状态名、转换起点终点、触发方式 | 业务负责人 |
| 条件与权限清单 | 条件类型、判断对象、权限方案名称 | 平台管理员 |
| 排除项 | 不迁移对象、原因、保留查询方式 | 迁移负责人 |
映射前的输入清单与依赖
映射的质量取决于输入材料是否完整。Jira侧需要导出或截图留存的内容包括：每个工作流的状态与转换全图、每条转换上配置的条件与校验、后处理动作（如自动更新字段、触发通知）、权限方案详情、项目角色成员、用户组结构，以及问题安全级别的使用情况。这些材料要标注导出时间和Jira版本，便于后续核对。
目标系统侧需要提前确认三项能力：状态机是否支持在转换上配置条件；角色与用户组模型能否承载Jira的项目角色和用户组；字段级和状态级的编辑控制是否存在对应机制。确认结果写成能力对照说明，作为映射时的判断依据。资料未覆盖的具体能力，在迁移前向目标系统厂商逐项确认，不凭界面印象下结论。
确认人安排上，业务方负责确认分支语义，例如“什么情况下允许从待验证回到开发中”；平台管理员负责确认权限边界，例如“哪些角色可以关闭问题”。每项材料标注来源、确认状态和确认人，形成输入清单与责任人表。缺少确认人的条目在映射表中标记为待定，不进入试迁移。
条件分支的映射方法
条件分支的映射按判断对象分类推进，比逐条对照界面更可靠。常见四类判断对象是：字段值（如优先级为高才允许转交）、用户或角色（如仅测试角色可执行验证通过）、子任务或关联问题状态（如子任务全部关闭才允许父任务完成）、权限前置（如无编辑权限则转换按钮不可见）。分类之后，每条转换的判断逻辑就能用统一口径描述。
关键动作是把转换条件与校验分开。条件决定这条转换是否出现或是否可执行，校验决定提交转换时是否放行。两者在Jira中配置位置不同，在目标系统中承载方式也可能不同。把校验误当成分支，会造成目标系统里多出并不存在的路径；把条件误当成校验，则会让本应隐藏的转换对所有人可见。映射表中为两者设置独立的类型列。
遇到无法等价表达的条件，采用降级方案并在表中标注：把多个相近分支合并为一条转换，用校验提示差异；把自动判断改为人工确认步骤，由指定角色在转换前核对；把差异过大的流程拆成独立工作流，按问题类型区分。降级方案要写明对业务的实际影响，例如“合并后审批环节由系统拦截改为人工检查”。
条件分支映射表建议包含以下列：Jira转换、条件类型、判断表达式、目标实现方式、等价程度（等价/近似/需人工处理）、差异说明、确认人。逐条填写后，等价程度为“需人工处理”的条目单独汇总，作为试迁移的重点观察对象。
在目标系统侧重建这些规则时，ONES Project支持迁移Jira的项目与系统配置，包括问题类型、工作流、字段配置和权限配置，可作为承载状态流转与条件配置的目标环境。具体到某条字段值条件或角色条件能否原样重建，仍需在迁移前按上述映射表逐项验证，确认后再写入配置。
权限规则的映射方法
权限映射先分层再对应。按控制粒度分为五层：项目级（谁能进入项目）、问题类型级（谁能创建某类问题）、状态级（谁能在某状态下编辑）、字段级（谁能修改某字段）、转换级（谁能执行某条转换）。Jira的权限方案通常把多层规则混在一个方案里，映射时要拆开逐层核对，避免整包照搬后出现某层缺失。
角色与用户组的对应是权限映射的核心。Jira项目角色通常对应目标系统中的项目角色或成员分组，Jira用户组对应目标系统的用户组。对应关系要写成角色对应表，逐行列出Jira角色名、成员来源（用户组或单人）、目标系统角色、成员同步方式。ONES的Jira迁移方案包含用户、用户组和系统配置的迁移，可作为账号与分组对应的起点；角色到权限点的具体授予关系仍需按目标系统的权限模型重新配置并核对。
按状态控制编辑与转换权限时，注意Jira中“状态内编辑权限”和“转换权限”是两套控制。目标系统若把两者合并管理，需要在映射表中记录这一差异，并评估影响：例如某角色在Jira中可以编辑但不能推进状态，合并后可能获得推进能力，属于权限放宽；反之则属于收紧。放宽和收紧都要逐条记录，交由业务方确认是否接受。
| 权限层级 | Jira侧对象 | 目标侧对应 | 差异处理 |
|---|---|---|---|
| 项目级 | 权限方案中的浏览项目 | 项目成员与可见范围 | 核对外部协作者是否仍可见 |
| 问题类型级 | 创建问题权限 | 问题类型创建权限 | 确认默认问题类型 |
| 状态级 | 编辑问题权限按状态 | 状态内编辑控制 | 记录合并或拆分差异 |
| 字段级 | 字段配置与界面方案 | 字段编辑权限 | 核对必填与只读组合 |
| 转换级 | 转换条件与权限 | 转换执行人限制 | 与条件分支映射表交叉核对 |
问题安全级别的使用情况要单独盘点。若Jira中大量工单设置了安全级别，映射到目标系统时需确认对应的可见性机制，并在试迁移中专门验证受限工单的可见范围。
试迁移与核验证据
试迁移的目的是用少量样例工单证明映射结果可用。样例选取遵循三条覆盖原则：每个条件分支至少一张工单走到该分支；每个权限边界至少一个典型角色尝试操作；每种问题类型至少一张工单完成完整流转。样例工单从Jira导出后迁入目标环境，按映射表配置的规则执行流转。
核验项按映射表逐条勾选：转换是否在满足条件时出现、在不满足时隐藏；无权用户执行转换时是否被正确拦截；字段在对应状态下是否可编辑、是否按预期只读；受限工单是否只对指定角色可见。每项核验保留操作记录或截图，与映射表行号对应，形成试迁移核验记录表。
核验记录表建议包含：核验项编号、对应映射表条目、操作角色、预期结果、实际结果、结论（通过/差异）、证据位置。发现差异后，回到映射表修订目标实现方式，重新配置后对该条目再验证一次，并在记录中保留修订前后两版结论，便于追溯。
回退点与停止条件
迁移过程中出现以下情况应暂停推进：关键分支在目标系统中无法表达且降级方案业务方不接受；试迁移中发现权限边界出现越权，即某角色获得了Jira中不具备的操作能力；核心角色无法完成其日常流转，导致业务无法运转。触发任一条件时，停止后续配置写入，先处理该问题再继续。
回退的前提是保留可恢复的基线。Jira原配置在切换完成前保持可查，不做删除或大范围改动；目标系统的配置按版本留存，每次批量修改前记录当前版本，回退时恢复到上一版本。试迁移使用的样例工单与正式数据分开存放，回退时一并清理，避免污染正式环境。
切换前的最终确认项包括：映射表中所有条目结论为通过或经业务方书面接受差异；核验记录表无未处理差异；回退方案和责任人明确；业务方确认分支语义与权限边界。确认项由迁移负责人汇总，业务负责人和平台管理员共同签字后，才进入正式切换。
常见问题
Jira中的转换条件和校验在目标系统里可以合并成一套规则吗？
不建议合并。转换条件决定这条转换是否出现或是否可执行，校验决定提交转换时是否放行，两者在Jira中配置位置不同，在目标系统中承载方式也可能不同。合并处理容易造成两种偏差：把校验当成分支，目标系统里会多出并不存在的路径；把条件当成校验，本应隐藏的转换会对所有人可见。映射表中为两者设置独立类型列，分别记录目标实现方式，试迁移时也分开核验。
Jira项目角色和用户组迁到目标系统后，成员关系会自动保持一致吗？
成员关系需要逐项核对，不能默认自动一致。Jira项目角色通常对应目标系统的项目角色或成员分组，Jira用户组对应目标系统的用户组，但成员来源可能是用户组、单人或多组叠加，对应后成员范围可能变化。做法是写角色对应表，逐行列出Jira角色名、成员来源、目标系统角色和成员同步方式，迁移后抽查典型角色的实际权限。ONES的Jira迁移方案包含用户、用户组和系统配置的迁移，可作为账号与分组对应的起点；角色到权限点的具体授予关系仍需按目标系统权限模型重新配置并核对。
试迁移要准备多少张样例工单才够？
数量取决于分支和权限边界的数量，不按固定张数。覆盖原则是：每个条件分支至少一张工单走到该分支，每个权限边界至少一个典型角色尝试操作，每种问题类型至少一张工单完成完整流转。一张工单可以同时覆盖多个核验项，但涉及互斥分支时需要分开准备。样例工单与正式数据分开存放，回退时一并清理。
权限映射后发现某角色权限被放宽，一定要回退吗？
不一定，取决于放宽是否触及业务底线。先判断放宽的具体范围：如果只是界面可见性变化，可由业务方确认后接受并记录；如果涉及审批、关闭、删除等关键操作，或让外部协作者看到受限工单，应视为越权风险，暂停配置写入并修正映射。所有放宽和收紧都逐条记录在权限映射表中，标注业务方确认结论，接受差异的条目在切换前书面留档。
Jira中依赖插件实现的条件逻辑，迁移时怎么处理？
先盘点再评估，不假设插件逻辑能一一对应。把插件实现的条件、校验和后处理动作单独列出，说明其判断对象和触发时机，再对照目标系统的原生条件能力判断能否重建。无法重建的部分进入降级方案：改为人工确认步骤、合并到相邻分支，或调整流程设计。ONES方案也提示，企业已有的定制场景在迁移前需要逐项评估，避免直接假设所有插件都能一一对应。
