迁移完成后发现工作流“不对劲”，先不用急着大改配置。把笼统的不一致拆成可观察的症状，用一条真实工作项复现，再对照迁移前的流程定义逐项验证原因，只修复确认存在差异的部分，最后用回归用例确认恢复。下面按症状界定、原因验证、分类型处置、回归与预防四步展开，并在处置环节说明 ONES 迁移场景下可借助的配置与记录能力。
要点总览（TL;DR）
- 先把“工作流不一致”拆成状态流转、审批节点、字段校验、自动化触发、权限可见性五类症状，并记录涉及的项目、工作项类型和角色，限定排查边界。
- 为每个原因假设找到可验证证据：流程定义对照、真实工作项的流转日志、审批记录、规则触发记录和不同角色的可见结果，按流程主干、分支与自动化、权限与通知的顺序排查。
- 处置遵循最小变更原则，只改与迁移前定义存在差异的项；批量调整状态、重绑审批人、放开权限前备份流程配置并设置停止点。
- 修复后用典型工单、需求、缺陷各走一遍完整流程做回归，设置观察期跟踪间歇性异常，并通过流程基线对照和变更评审防止复发。
先界定不一致的范围与症状
“工作流不一致”本身不是可排查的对象，需要先落到具体行为上。建议拿迁移前的一个典型项目做参照，逐项比对，把差异写成清单，而不是停留在“感觉流程变了”的印象里。
常见症状可以归为五类：
- 状态流转缺失或多余：原来能从“待处理”直接到“已完成”，迁移后必须先经过“测试中”；或者多出迁移前没有的状态节点。
- 审批节点错位：审批环节出现在流转的错误位置，或审批人变成了空值、默认管理员。
- 字段必填与校验差异：迁移前提交缺陷必须填严重程度，迁移后可以留空；或原本选填的字段变成必填，导致无法提交。
- 自动化触发未生效：状态变更后应自动通知负责人、自动指派处理人，迁移后没有动作。
- 权限与可见性差异：同一角色的成员看不到应有的工作项，或看到了迁移前无权访问的项目。
确认影响范围时，至少记录三项：涉及哪些项目、哪些工作项类型（需求、缺陷、工单等）、哪些角色受影响。范围记录的作用是限定后续排查和修复的边界，避免在单个项目上反复试错却漏掉同类问题。
还需要区分行为不一致与数据搬运问题。状态名称对不上、字段值丢失、附件缺失属于数据迁移与映射范畴，应回到迁移映射环节处理；本文讨论的是流程定义、规则、权限等行为层面的差异。两类问题混在一起排查，容易把配置问题误判成数据问题。
逐项验证原因假设并收集排除证据
症状清单出来后，下一步是把可能原因写成假设，并为每个假设找到可验证的证据。排查中最常见的失误是把“看起来像”的原因直接当成结论，改完配置后问题依旧，反而增加了新的变量。
下表列出常见原因假设与对应的验证方式，可按实际症状选用：
| 原因假设 | 典型症状 | 验证证据 |
|---|---|---|
| 流程定义未完整迁移 | 状态或流转缺失、分支条件丢失 | 导出迁移前后的流程定义逐节点对照，标出差异项 |
| 状态与状态类别映射错位 | 看板列归组错误、统计口径变化 | 检查每个状态所属类别（如“进行中”“已完成”）是否与迁移前一致 |
| 审批与角色绑定丢失 | 审批人为空、审批环节被跳过 | 用测试账号发起一条审批，查看审批记录中的实际审批人 |
| 自动化规则依赖条件变化 | 通知、指派、状态联动未触发 | 查看规则触发记录，核对触发条件引用的字段、状态是否仍存在 |
| 权限方案差异 | 可见范围过大或过小 | 用不同角色的测试账号分别打开同一工作项，记录可见结果 |
验证时尽量用一条真实工作项走完整流程，并保留流转日志、审批记录和规则触发记录。日志能回答“实际发生了什么”，比回忆迁移前的操作更可靠。对于自动化规则，重点核对触发条件中引用的字段和状态在迁移后是否仍然存在、名称是否变化，条件失效往往表现为规则静默不执行。
排查顺序建议先流程主干，再分支与自动化，最后权限与通知。主干（状态与流转）是其他行为的基础，主干未对齐时，自动化与权限的测试结果会互相干扰。每排除一个假设，就在假设表上记录证据和结论，形成可回溯的排查记录。
按差异类型执行处置步骤
原因确认后，处置遵循最小变更原则：只改与迁移前流程定义存在差异的项，改动前保留对照，改动后记录变更人和时间。以下按差异类型给出处置路径。
流程定义差异
补齐缺失的状态与流转，或删除迁移后多出的节点。调整时保留变更前后的流程定义对照，便于回退和后续复核。涉及已在流转中的工作项时，先确认状态调整对存量数据的影响，再决定是否批量处理。
审批与角色
重新绑定审批人与角色，明确代理和转交规则。审批人绑定建议按角色而非具体个人配置，减少人员变动带来的再次失效。重绑后立即用测试工作项发起一次审批，确认审批人能收到并处理。
自动化规则
核对触发条件与执行动作，修正引用已变更字段或状态的规则。修改后先在测试项目验证触发效果，确认无误再应用到正式项目。规则较多时逐条验证，避免一次改动多条后无法判断哪条生效。
权限与可见性
按角色调整可见范围，避免一次性放开全部权限来“先让流程跑通”。权限放宽容易，收回时往往已经产生越权访问。调整后分别用受限角色和管理角色验证可见结果。
破坏性操作前需要设置停止点：批量调整状态、重绑审批人、放开权限之前，先备份流程配置，记录变更人，并明确出现异常时的回退方式。若迁移范围包含流程、字段、权限等系统配置，可先核对迁移结果与迁移前定义的对应关系，再决定改哪里。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，迁移项目时也包含问题类型、工作流、字段配置、权限配置等系统配置，这些迁移结果可以作为对照基线；具体迁移项以实际迁移工具与实施方案为准。
对于原来依赖插件的自动化场景，ONES 建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配；企业已有的定制场景需要逐项评估，不宜假设所有插件都能一一对应。这类场景在处置时更适合先确认替代方案的行为边界，再调整规则。
回归验证与复发预防
修复完成不等于恢复。需要用回归用例确认行为与迁移前一致，并建立机制防止同类差异再次出现。
回归用例建议覆盖典型工单、需求、缺陷各一条，每条走完整流程，验证以下证据：
- 流转日志：状态按预期顺序变化，无跳过或多余节点。
- 审批记录：审批环节出现在正确位置，审批人正确，代理与转交可用。
- 自动化执行记录：通知、指派、状态联动按规则触发。
- 权限结果：不同角色看到的工作项范围符合预期。
回归通过后设置观察期，指定责任人跟踪一段时间内的异常反馈，重点看是否有规则间歇性不触发、审批卡住等不易在单次测试中暴露的问题。观察期内收到的异常，回到症状清单补充记录，形成闭环。
预防动作包括三项：迁移后做一次流程基线对照，把迁移前后的流程定义、字段配置、权限方案差异记录在案；流程与权限的变更走评审，避免个人直接修改；保留配置变更记录，出现不一致时能快速定位最近一次改动。ONES 方案把迁移工具、原厂服务和分阶段切换结合，在正式迁移前确认数据范围、功能匹配和系统适配，以数据完整、业务连续和系统稳定为目标，这类前置确认同样能减少迁移后的行为差异；具体实施方式以实际服务方案为准。
把上述四步固化为迁移后的检查习惯：症状清单、假设与证据表、最小修复记录、回归用例，下次迁移或平台调整时可以直接复用，减少重复排查的成本。
常见问题
迁移后只有部分项目出现工作流不一致，需要全部项目一起排查吗？
不必。先按项目、工作项类型和角色记录受影响范围，把出现差异的项目列为优先排查对象，未受影响的项目作为对照基线。排查时优先选一个症状最典型、使用人数较多的项目复现问题，确认原因和修复方式后再评估同类项目是否存在相同差异。若多个项目共用同一套流程定义或权限方案，修复前先确认改动的影响面，避免在一个项目上调整后波及其他项目。
修复工作流差异时，已经在流转中的工作项会受影响吗？
取决于改动类型。调整状态与流转、删除节点可能影响存量工作项当前所处的状态，批量处理前应先确认这些工作项是否需要同步迁移到新状态，并保留变更前后的流程定义对照。审批人重绑、自动化规则修改通常只影响后续触发，但也要用一条存量工作项验证。涉及批量调整状态、重绑审批人、放开权限等操作时，先备份流程配置、记录变更人，并明确异常时的回退方式。
自动化规则在迁移后没有报错，但也没有执行，怎么判断原因？
先看规则触发记录，确认规则是否被触发。若未触发，重点核对触发条件中引用的字段和状态在迁移后是否仍然存在、名称是否变化，条件失效常表现为规则静默不执行。若已触发但动作未生效，检查执行动作指向的负责人、通知对象或目标状态是否有效。修改规则时逐条验证，先在测试项目确认触发效果，再应用到正式项目，避免一次改动多条后无法判断哪条生效。
迁移前依赖插件实现的自动化，迁移后应该怎么处理？
先梳理实际使用的插件及其承担的动作，再逐项确认替代方案的行为边界。ONES 建议通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配，企业已有的定制场景需要逐项评估，不宜假设所有插件都能一一对应。确认替代方案后，用测试工作项验证触发条件和执行结果，再替换原有规则；行为边界不完全一致的场景，需要调整流程设计或补充人工环节。
回归验证通过后，还需要观察多久？
没有统一时长，建议根据流程使用频率和影响范围确定：高频使用的工单或缺陷流程，观察期可以短一些但覆盖完整的处理周期；低频审批或跨团队流程，观察期应至少覆盖一次完整流转。观察期内指定责任人跟踪异常反馈，重点看规则间歇性不触发、审批卡住等单次测试不易暴露的问题。收到的异常回到症状清单补充记录，确认修复后再结束观察。
