从Jira迁出时，状态和审批最容易出现“数据搬过去了、规则没跟过去”的情况。检查的核心是把Jira工作流拆成状态集合与类别、流转条件与权限、审批节点与审批人规则、历史状态轨迹四类语义，逐项映射并标注等价、近似或缺失，再用同一批样例工单回放验证。本文按盘点、准备、映射、核验、回退的顺序给出可执行方法。
要点总览（TL;DR）
- 把Jira工作流拆成状态集合与类别、流转条件与权限、审批节点与审批人规则、历史状态轨迹四类语义，逐项建立源端基线，是检查是否保留的起点。
- 映射结果统一标注为等价、近似、缺失三档；缺失项要写明降级方案和人工补偿点，不能默认迁移工具会自动保留全部规则。
- 审批语义重点核对节点绑定位置、审批人来源、多人审批通过规则和驳回后走向，并确认历史审批记录能否随工单查看。
- 用覆盖正常、驳回和异常路径的样例工单回放，对比当前状态、历史状态序列、审批结论和审批时间，形成可追溯的对照记录。
- 审批结论丢失、关键状态无法到达、权限越权属于阻断级差异，应先暂停切换处理；回退触发条件和切换期观察责任人需在切换前约定。
先界定迁移范围：哪些状态和审批需要保留
语义检查的第一步是确定检查对象，避免把整个Jira实例的所有工作流一次性铺开。盘点应以“项目—问题类型—工作流方案”为线索展开：先列出本次迁移涉及的项目，再确认每个项目下各问题类型绑定了哪个工作流方案，最后从工作流方案中提取状态、流转和审批节点的完整清单。同一个工作流方案可能被多个项目复用，盘点时按方案去重，核对时再按项目确认实际使用情况。
盘点结果需要给每一项语义标注保留等级，建议分为三类：
- 必须保留：影响业务合规、审批留痕或关键决策路径的状态与审批，例如发布审批、变更审批、验收通过等节点，以及与之绑定的状态流转。
- 可简化：中间过渡状态、重复的审批环节、仅用于提醒的流转，可以在目标端合并或减少节点，但需业务方确认。
- 可放弃：已停用的问题类型、历史遗留的废弃状态、无人使用的审批路径，明确记录后不再纳入映射。
同时要记录Jira的版本信息和工作流配置来源，包括配置是项目级还是全局级、是否依赖插件实现审批或条件校验。这份记录构成后续比对的基线，一旦迁移过程中出现争议，可以回到基线确认原始语义。对于依赖插件的审批场景，迁移前应逐项评估目标端是否有对应能力，不能假设插件功能会自动对应。
本阶段输入与依赖：检查前要准备哪些材料
语义检查的质量取决于输入材料是否完整。执行前建议准备以下几类材料，并明确每类材料的责任人：
| 材料类别 | 具体内容 | 责任人 |
|---|---|---|
| 工作流配置 | 工作流方案导出、状态清单、流转关系图、条件与校验配置、权限方案 | Jira管理员 |
| 审批规则说明 | 审批节点位置、审批人来源、多人审批通过规则、驳回后走向，可用截图或文字说明 | 流程负责人 |
| 样例工单 | 覆盖主要问题类型和关键审批节点的代表性工单，含历史状态变更记录与审批记录 | 业务方与Jira管理员 |
| 语义解释确认 | 业务方对每个审批节点实际含义的说明，特别是同名但用途不同的审批 | 业务方 |
样例工单的选择直接影响核验效果。建议每个主要问题类型至少选取若干条工单，覆盖正常通过路径、被驳回路径和长期停留在中间状态的异常路径。工单的历史记录要能导出，包括状态变更时间、操作人和审批结论。
材料缺失时的处理方式需要提前约定：配置无法完整导出时，以截图和人工整理补足，并标注信息来源；业务方无法确认审批语义时，暂按“必须保留”处理，待确认后再调整等级；样例工单不足时，扩大抽样范围或补充构造测试工单，但构造工单需明确标注，不能与真实工单混用作为证据。
状态语义映射：名称、类别与流转条件逐项对照
状态映射不能只对照名称，还要对照状态类别和流转条件。Jira中的状态类别决定了状态在敏捷看板、报表中的归类，例如“进行中”“已完成”，目标端如果没有同等类别划分，报表口径会发生变化。映射时建议建立一张对照表，每个状态一行，记录源端名称、源端类别、目标端名称、目标端类别、映射结果和备注。
流转条件的映射同样需要逐条核对。Jira的流转可以配置条件、校验和权限，例如仅允许特定角色执行某次流转、流转前必须填写某字段。目标端如果只还原了状态和流转方向，却遗漏了条件与权限，就会出现本应受限的流转对所有人开放的情况。核对时应把每条流转的条件和权限单独列出，确认目标端是否有对应配置，以及配置的作用范围是否一致。
常见的问题有三类，处理原则如下：
- 同名不同义：两个状态名称相同但业务含义不同，例如两个项目中的“已评审”分别指技术评审和业务评审。应按业务含义分别映射，必要时在目标端改名以区分，不能因为名称相同就合并。
- 同义不同名：名称不同但含义一致的状态，可以映射到同一目标状态，但需在对照表中记录合并关系，并确认合并后历史轨迹的展示方式。
- 状态类别错位：目标端类别划分与Jira不同，需明确每个状态归入哪个类别，并检查报表和看板口径是否随之变化。
无法映射的状态要给出降级方案。常见做法包括：合并到最接近的状态并保留原状态名作为标签或字段值；保留独立状态但简化其流转条件；对确实无法承载的语义，设置人工补偿点，例如由流程负责人在迁移后定期检查某类工单并手动补录审批结论。降级方案要写清楚补偿动作、执行人和检查频率，不能只写“后续处理”。
审批语义映射：节点、审批人与通过规则如何核对
审批语义是迁移中最容易失真的部分。核对时按四个维度展开：审批节点的位置与触发条件、审批人来源、多人审批的通过规则、审批记录是否随工单保留。
审批节点的位置指审批发生在哪次状态流转上，触发条件指什么情况下需要审批。例如“提交发布申请”流转到“待审批”状态时触发审批，与“审批通过”流转到“已发布”时记录结论，是两种不同的绑定方式。映射时要确认目标端的审批是绑定在状态上、流转上还是独立流程上，绑定位置不同会影响审批的触发时机和驳回后的走向。
审批人来源需要逐项对照。Jira中审批人可能来自固定人员、项目角色、用户组或字段值，目标端如果只支持固定审批人，角色和字段驱动的审批就需要改为人工指定或通过其他机制实现。多人审批的通过规则同样要核对：全部通过、任一通过、按比例通过，以及驳回后工单回到哪个状态、是否需要重新发起。这些规则如果只还原了审批节点而遗漏了通过规则，审批结论的可信度会下降。
| 核对维度 | 源端记录内容 | 目标端确认内容 | 映射结果 |
|---|---|---|---|
| 审批节点位置 | 绑定在哪次流转、触发条件 | 审批绑定方式与触发时机 | 等价/近似/缺失 |
| 审批人来源 | 固定人员、角色、字段或用户组 | 目标端支持的审批人指定方式 | 等价/近似/缺失 |
| 多人审批规则 | 全部通过、任一通过等 | 目标端通过规则配置 | 等价/近似/缺失 |
| 驳回后走向 | 回到哪个状态、是否重新发起 | 驳回后的状态流转配置 | 等价/近似/缺失 |
| 审批记录 | 审批人、结论、时间、意见 | 记录是否随工单保留及展示位置 | 等价/近似/缺失 |
审批记录是否随工单保留，直接关系到迁移后的可追溯性。核对时应确认历史审批结论、审批时间和审批意见在目标端能否查看，以及展示形式是否便于审计。对于依赖插件实现的审批场景，迁移前需要梳理实际使用的插件，再评估目标端通过流程配置、自动化或开放能力进行功能匹配的可行性；企业已有的定制审批场景仍需逐项评估，不能假设所有插件都能一一对应。
在目标端承载工作项状态与审批流程时，ONES Project 支持迁移项目、问题类型、工作流、字段配置和权限配置，也迁移工作项属性、附件和评论等信息，可作为状态与审批映射的落地载体。审批节点、审批人规则和历史审批记录的具体还原程度，需在迁移方案中逐项确认并纳入核验范围。
核验与证据：用样例工单回放验证语义保留
映射表完成之后，需要用实际工单验证语义是否真的保留。回放验证的基本做法是：选取迁移前已导出的样例工单，在目标端找到对应工单，对比当前状态、历史状态序列、审批结论和审批时间四项内容，逐条记录差异。
抽样应覆盖主要问题类型、关键审批节点和异常路径。正常路径验证主流程是否通畅，驳回路径验证审批结论和状态回退是否正确，异常路径验证长期停留、重复审批、跨项目流转等边界情况。每个关键审批节点至少有一条工单覆盖，避免只验证了流程起点和终点。
证据留存建议采用对照记录表加截图或导出数据的方式。对照记录表每个工单一行，列出源端状态序列、目标端状态序列、源端审批结论、目标端审批结论和差异说明；截图用于固定关键节点的页面状态，导出数据用于批量比对。证据要能追溯到具体工单和具体时间点，便于后续复核。
判定标准建议分为三档：
- 通过：状态序列、审批结论和审批时间与源端一致，或差异在事先约定的可接受范围内。
- 需修正：存在状态名称或类别差异、审批人展示方式不同等不影响结论的问题，记录后限期修正。
- 不可接受：审批结论丢失、关键状态无法到达、审批记录缺失导致无法追溯，此类差异必须处理后再继续。
回退与停止条件：哪些差异必须先处理再切换
语义检查发现差异时，需要区分哪些可以带风险上线、哪些必须暂停处理。阻断级差异包括：审批结论丢失或错位，导致已审批工单在目标端显示为未审批；关键状态无法到达，导致业务流程走不通；权限配置错误导致越权操作，例如普通成员可以执行本应受限的审批流转。出现这类差异时，应暂停切换，修正后重新抽样验证。
可以带风险上线并限期修复的差异，通常是不影响审批结论和流程可达性的问题，例如状态名称措辞不同、审批意见展示位置变化、历史轨迹的排序方式不同。这类差异需要明确修复责任人和期限，并在切换后的观察期内跟踪。
回退触发条件应在切换前约定，例如切换后一定时间内发现阻断级差异数量超过约定阈值，或核心项目出现无法推进的工单。回退后的数据一致性处理同样要提前设计：切换期间在目标端产生的工单和审批记录，回退时需要评估是保留、导出还是重新录入，避免两边数据冲突。切换窗口内应安排专人观察核心项目的状态流转和审批队列，发现异常立即上报，观察点和责任人列入切换检查表。
常见问题
Jira工作流迁移时，状态名称相同但业务含义不同，应该怎么处理？
按业务含义分别映射，不能因为名称相同就合并。例如两个项目中的“已评审”分别指技术评审和业务评审，应映射到目标端两个不同状态，必要时改名以区分。对照表中要记录原名称、业务含义和映射去向，避免迁移后报表把两类评审混在一起统计。
审批人来自Jira项目角色或字段值，目标端只支持固定审批人时怎么办？
先确认目标端支持的审批人指定方式，再决定降级方案。常见做法是由流程负责人按项目角色或字段值人工指定审批人，或通过目标端的自动化能力按字段分派。降级后要在对照表中标注为“近似”，并写明补偿动作和执行人，同时在抽样回放中重点验证这类审批的触发和结论是否正确。
样例工单回放时，哪些差异可以带风险上线，哪些必须暂停？
审批结论丢失或错位、关键状态无法到达、权限配置导致越权操作，属于阻断级差异，必须暂停切换并修正后重新抽样。状态名称措辞不同、审批意见展示位置变化、历史轨迹排序方式不同等不影响结论和流程可达性的问题，可以带风险上线，但需明确修复责任人和期限，并在切换后的观察期内跟踪。
迁移后发现语义差异需要回退，切换期间在目标端产生的数据怎么处理？
回退前要评估切换期间在目标端新增的工单和审批记录，明确是保留、导出还是重新录入，避免两边数据冲突。建议在切换前就约定回退触发条件和数据处置方式，回退后由责任人核对核心项目的状态和审批队列，确认没有遗漏后再恢复原系统运行。
依赖Jira插件的审批流程，迁移前需要做哪些额外确认？
先梳理实际使用的插件及其承担的审批或流转功能，再评估目标端通过流程配置、自动化或开放能力进行功能匹配的可行性。企业已有的定制审批场景需要逐项评估，不能假设所有插件都能一一对应。ONES的方案建议在正式迁移前确认数据范围、功能匹配和系统适配，插件相关场景应纳入这一确认范围。
