把Jira工作流迁到新平台时，条件分支和权限规则需要分开处理。条件分支先还原成“触发条件—判断依据—去向”的规则清单，再在新平台用状态流转条件、字段校验或自动化规则重建；权限规则按角色、项目、问题类型、状态四层拆解，映射到项目角色、空间成员和工作流级权限。两类规则都难以整段照搬，需要逐条对照、抽样试跑并保留回退点。本文按迁移范围、输入准备、两类映射、核验与回退的顺序展开。
要点总览（TL;DR）
- 条件分支先拆成“触发条件—判断依据—去向”三要素，再在新平台用状态流转条件、必填校验或自动化规则逐条重建，原生规则优先，脚本最后考虑。
- 权限规则按项目与空间、角色与成员、状态级权限三层拆解，逐项比对权限集合，个人特例单独列出确认。
- 映射表要标注等价程度（等价/近似/降级），无法直接对应的条件改为人工检查或审批节点，并记录确认人。
- 试迁移选流程复杂、权限分层明显、数据量大的典型项目，用不同角色账号验证实际行为，输出验证记录与差异清单。
- 关键审批或合规权限无法等价重建、条件分支出现漏判时暂停切换，过渡期保留Jira只读或并行运行。
迁移范围：先界定哪些条件分支和权限规则要迁
迁移范围决定后续工作量。建议先锁定一个Jira实例版本、若干试点项目和目标平台的一个测试空间，把“全量搬迁”拆成“先迁哪些、后迁哪些、哪些不迁”。范围清单同时登记条件分支和权限规则两类对象，避免只关注状态流转而漏掉访问控制。
条件分支清单按工作流逐个登记：状态流转条件（谁能执行某次流转）、校验规则（流转前必须满足的字段或子任务条件）、后置动作（流转后自动更新字段、通知或创建关联事项）。每条记录所属工作流、适用问题类型和当前触发效果。
权限规则清单覆盖四类对象：项目权限方案及其中的浏览、创建、编辑、流转、删除等权限项；问题安全级别及其成员；项目角色与用户组、用户的对应关系；按状态限制操作的特殊配置。清单要标注每条规则影响的人群和业务后果，便于判断取舍。
取舍口径可以按三条判断：仍在支撑当前研发流程的规则保留并逐条映射；长期未触发或已被其他机制覆盖的规则简化或合并；与已下线业务绑定的规则登记后废弃。涉及审批、合规、跨团队数据隔离的规则一律保留，并单独标记为高优先级。最终形成一份带“保留/简化/废弃”结论的迁移范围清单，由项目管理员和研发负责人共同确认。
本阶段输入与依赖：迁移前要准备哪些材料
映射工作依赖可核对的原始配置，而不是记忆中的流程。开工前把材料备齐，并明确每项材料的提供人和确认人。
- 工作流导出与留档：导出Jira工作流定义、条件与校验配置、后置功能列表；对管理后台中的权限方案、问题安全级别、角色成员页面逐页截图，标注导出日期，作为迁移后比对的基线。
- 角色与用户组名单：整理Jira中的用户组、项目角色及其成员，标明哪些角色是全局复用、哪些是单项目配置；同时确认目标平台的账号开通情况和组织架构同步方式。
- 基础对照表：先建立字段、状态、问题类型的对照表，例如Jira的“待办/进行中/已完成”对应目标平台的哪些状态，自定义字段对应哪些工作项属性。条件分支和权限规则都建立在这张表之上，对照表未定之前不宜开始逐条映射。
- 目标平台环境：准备一个独立测试项目，确认管理员具备配置工作流、角色和权限的账号；测试项目的数据与生产隔离，允许反复调整配置。
材料清单建议附责任分工：配置导出由Jira管理员负责，角色名单由项目负责人确认，字段对照由业务方和平台管理员共同评审，测试环境由平台管理员准备。若迁移目标为ONES Project，其Jira迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，系统配置中包括问题类型、工作流、字段配置和权限配置，用户与用户组也在迁移范围内；实际迁移前仍应以上述材料逐项核对，确认哪些配置随迁移带入、哪些需要在目标平台重新配置。
条件分支怎么映射：从Jira条件到新平台流转规则
条件分支的映射方法是逐条拆解、逐条重建。把每个Jira条件写成三要素：触发条件（在哪个状态、执行哪个动作时判断）、判断依据（权限、字段值、子任务状态、用户角色等）、去向（满足时允许流转或执行后置动作，不满足时阻止并提示）。三要素写清后，再为目标平台选择承载方式。
| Jira条件类型 | 判断内容示例 | 新平台常见承载方式 | 验证方式 |
|---|---|---|---|
| 权限条件 | 仅项目角色“开发”可执行“开始开发” | 状态流转条件绑定项目角色或空间成员 | 用无权限账号尝试流转，确认被阻止 |
| 字段值条件 | “影响版本”为空时不允许关闭 | 流转前必填校验或字段校验规则 | 清空字段后尝试流转，确认提示缺失项 |
| 子任务状态条件 | 所有子任务完成后父任务才能关闭 | 自动化规则检查关联工作项状态，或流转校验 | 保留一个未完成子任务，确认父任务流转被拦截 |
| 用户角色条件 | 仅报告人或经办人可重新打开 | 流转条件限定为特定人员字段或角色 | 分别用报告人、经办人、无关人员账号测试 |
新平台的承载方式通常有四类：状态流转条件用于控制“谁能从哪个状态走到哪个状态”；必填校验和字段校验用于控制“流转前数据是否完整”；自动化规则用于处理跨工作项判断，例如子任务全部完成、关联缺陷关闭等；脚本或插件用于表达平台原生规则难以覆盖的复杂逻辑。选择顺序建议先用原生流转条件和校验，再用自动化规则，最后才考虑脚本，以降低后续维护成本。
无法直接对应的条件要明确降级方案，不能默认放行。常见做法包括：把自动判断改为流转时的人工检查项，在表单中增加确认字段；把复杂条件改为审批节点，由指定角色确认后放行；把仅用于提醒的条件改为通知规则，不阻断流转。每条降级都要记录原因和确认人，并在映射表中标注“非等价实现”。
映射表建议包含五列：Jira条件编号与描述、三要素拆解、新平台实现方式、等价程度（等价/近似/降级）、验证用例。等价程度一列是后续核验和回退判断的依据。ONES的Jira迁移方案覆盖工作流配置迁移，并结合流程自动化承接常用插件场景；对于依赖定制脚本或特殊插件的条件逻辑，迁移前仍需逐项评估，确认用流转条件、校验还是自动化规则重建。
权限规则怎么映射：角色、项目与状态三层拆解
Jira权限体系的核心是“权限方案+项目角色+问题安全级别”的组合，新平台的权限模型通常按空间、项目角色和工作流分别配置。映射时按三层拆解，逐层确认对应关系。
第一层是项目与空间。Jira的每个项目对应新平台的一个项目或空间，项目权限方案中的浏览、创建、管理类权限，对应到空间成员角色和项目角色。需要确认哪些人是空间管理员、哪些人是普通成员、哪些人只读。跨项目共享的角色在Jira中可能复用同一权限方案，迁移后要检查目标平台是否支持同等范围的复用，避免逐项目重复配置导致遗漏。
第二层是角色与成员。Jira项目角色下的用户组和用户，对应到新平台的项目角色成员。映射时以用户组为主、个人为辅：组对组的对应关系稳定，个人特例要单独列出并确认是否仍然需要。角色名称可以不同，但权限集合要逐项比对，例如“开发”角色在Jira中可编辑、可流转、不可删除，在新平台中要找到对应的权限组合。
第三层是状态级权限。Jira中按状态限制编辑、流转、查看的规则，对应到新平台的工作流级权限和流转条件。典型场景包括：已关闭事项仅管理员可重新打开；特定状态下字段只读；敏感问题类型仅指定角色可见。这类规则最容易在迁移中被简化成“全员可操作”，需要逐条登记并在测试中验证。
| Jira权限对象 | 拆解要点 | 新平台对应位置 | 风险提示 |
|---|---|---|---|
| 项目权限方案 | 浏览、创建、编辑、管理权限分别授予哪些角色 | 空间成员角色与项目角色权限 | 方案复用关系丢失导致逐项目配置不一致 |
| 问题安全级别 | 哪些级别、哪些成员可见 | 工作项可见范围或空间隔离 | 安全级别被忽略导致敏感事项扩大可见 |
| 项目角色成员 | 用户组与个人的对应关系 | 项目角色成员与用户组 | 个人特例遗漏或组映射错误 |
| 状态级操作限制 | 按状态限制编辑、流转、查看 | 工作流级权限与流转条件 | 被简化为统一权限，边界放宽 |
权限映射的风险主要来自两个方向。收紧过度会让原本能正常流转的角色被阻断，影响交付节奏；放宽过度则可能让敏感项目或安全级别内的事项被更多人看到。每条差异都要记录“原规则—新规则—差异方向—确认人”，涉及合规、审批和跨团队隔离的差异由项目负责人和安全或合规接口人共同确认，确认记录随映射表归档。
在ONES中，项目角色、空间成员和工作流配置共同承担访问与操作控制，Jira迁移方案包含权限配置的迁移。由于各平台权限模型的粒度不同，迁移后仍需按上述三层逐项核对实际效果，不能仅凭配置项名称一致就判定等价。
核验与证据：试迁移后怎么确认映射正确
映射表完成不等于迁移正确，需要用试迁移验证实际行为。建议选取两到三个典型项目：一个流程复杂、条件分支多的研发项目，一个权限分层明显的跨团队项目，再加一个历史数据量较大的项目。试迁移在测试环境中进行，不影响生产使用。
条件分支的验证按映射表逐条执行：为每条规则准备一个应通过用例和一个应拦截用例，记录实际结果与预期是否一致。重点检查边界情况，例如字段为空、子任务部分完成、用户同时属于多个角色。出现漏判或误判时，回到映射表定位是实现方式选择不当还是配置遗漏。
权限验证用不同角色账号实际操作，而不是只看配置页面。至少覆盖：项目管理员、普通开发、只读成员、外部协作人员四类账号，分别尝试浏览、创建、编辑、流转、重新打开已关闭事项。对问题安全级别或敏感项目，用无权限账号确认不可见，用有权限账号确认可见。验证结果以截图和操作记录留存。
试迁移结束后输出两份材料：验证记录（用例、账号、预期、实际、结论）和差异清单（与Jira原规则的偏差、原因、处理决定、责任人）。差异清单中的每一项都要有明确结论：修复配置、接受差异或回退该条规则，不能留待切换后再处理。
回退与停止条件：哪些情况先暂停切换
迁移过程中需要预设暂停和回退的判断条件，避免问题在切换后才暴露。以下情况建议暂停推进：关键审批流程或合规相关权限无法在新平台等价重建；问题安全级别对应的可见范围无法保证；核心工作流的条件分支出现漏判，导致本应拦截的流转被放行；试迁移中发现的差异清单存在未关闭的高优先级项。
出现条件分支误判时，回退方式是把该条规则恢复为Jira中的原配置，在新平台侧暂时改为人工检查或审批节点，待配置修正并重新验证后再切换。权限规则出现放宽时，优先收紧到最小可用范围，再逐步放开，避免先宽后紧造成数据暴露。
过渡期建议保留Jira只读访问或短期并行运行：新平台承接新增工作项，Jira保留历史查询能力，待试迁移验证通过、差异清单关闭后再停止Jira写入。并行期间明确两边数据的归属，避免同一事项在两端重复更新。
切换前由项目管理员、研发负责人和平台管理员共同做最终确认，确认内容包括：映射表与差异清单已关闭、试迁移验证记录完整、回退方案可执行、各角色账号已开通并验证。确认结果签字或留档后，再执行正式切换。
常见问题
Jira里用脚本或插件实现的条件逻辑，迁到新平台后怎么处理？
先判断这段逻辑属于哪类判断：字段值校验、角色限制、跨工作项状态检查，还是多条件组合。能用新平台原生流转条件或必填校验表达的直接重建；涉及子任务、关联事项联动的，用自动化规则承接；只有原生规则和自动化都覆盖不了的复杂组合，才考虑脚本或插件。
无法等价实现时不要默认放行，改为流转时的人工确认字段或审批节点，并在映射表中标注“降级实现”和确认人。ONES的迁移方案结合流程自动化承接常用插件场景，定制逻辑仍需迁移前逐项评估。
问题安全级别在迁移中容易被忽略，怎么保证敏感事项的可见范围不变？
把问题安全级别单独列入权限规则清单，登记每个级别的成员范围和对应的问题类型。迁移时确认新平台用工作项可见范围还是空间隔离来承接，两者粒度不同，不能按名称直接对应。
试迁移阶段用无权限账号确认不可见、有权限账号确认可见，验证结果截图留存。涉及跨团队数据隔离的安全级别，由项目负责人和合规接口人共同确认差异后再切换。
试迁移要跑多久、覆盖多少项目才算够？
没有统一时长，判断标准是覆盖度而非天数。建议至少覆盖三类项目：条件分支多的复杂研发流程、权限分层明显的跨团队项目、历史数据量大的项目。每条条件分支准备应通过和应拦截两个用例，权限用项目管理员、普通开发、只读成员、外部协作人员四类账号分别操作。
当差异清单中的高优先级项全部关闭、验证记录完整可查时，即可进入切换确认，不必追求全量项目试跑。
迁移期间Jira还能继续用吗？两边数据怎么分工？
可以保留过渡期并行：新平台承接新增工作项，Jira保留历史查询和只读访问，待试迁移验证通过、差异清单关闭后再停止Jira写入。并行期间要明确同一事项只在一端更新，避免两端重复修改造成状态不一致。
如果关键审批或合规权限尚未等价重建，应暂停切换而不是带问题上线，先修正配置并重新验证。
ONES能直接迁移Jira的工作流和权限配置吗？迁移后还要做什么？
ONES的Jira迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，系统配置中包括问题类型、工作流、字段配置和权限配置，用户与用户组也在迁移范围内。迁移后仍需按本文方法逐项核对：条件分支的实际触发效果、各角色账号的权限边界，都要在测试环境中验证，配置项名称一致不代表行为等价。
