迁移完成后发现工单流转与原来对不上，是工具切换中常见的问题。不一致通常来自两类地方：源系统与目标系统在工作流模型上的语义差异，以及迁移过程中状态、流转条件、字段规则、权限和扩展能力的映射丢失或重建偏差。下面按“症状—原因—处置—验证”的顺序展开，帮助你把模糊的“不一致”拆成可核对的现象，逐项定位并恢复。
要点总览（TL;DR）
- 迁移后工作流不一致通常表现为状态名称或数量对不上、流转被阻断或跳过、条件与校验丢失、字段权限异常、通知与自动化失效五类现象。
- 主要原因可归为工作流模型差异、映射缺失、重建偏差、扩展能力差异和运行环境差异，每类都需要对应的证据来源来验证或排除。
- 排查按“典型工单端到端走查—对照源系统配置核对—区分配置缺失与能力不支持—小范围验证后推广”的顺序推进，批量改配置前先备份并设停止点。
- 恢复验证用覆盖主要流转分支的回归用例，并对比迁移前后关键工单的流转记录；把根因补进迁移检查清单可减少复发。
- ONES 的迁移方案覆盖项目、工作项、状态、字段、流程、权限等系统配置，复杂流转规则与插件替代仍需在具体迁移评估中逐项确认。
迁移后工作流不一致有哪些典型表现
排查的第一步是把“不一致”具体化。同一句“流程不对”，在不同团队那里可能指完全不同的现象，处置方式也相差很远。建议先收集近期的实际工单，按下面几类现象归类记录，形成一份症状清单，作为后续对照排查的锚点。
- 状态对不上：目标系统的状态名称、状态数量与源系统不一致，例如源系统有“待评审”“评审中”“评审通过”三个状态，目标系统只剩“评审中”和“已完成”；或者状态名称相同但含义被改变，导致经办人按旧习惯操作时选错状态。
- 流转被阻断或跳过：同一操作在源系统可以正常推进，在目标系统提示无权限、缺少必填项或直接跳到下一环节。典型如提交评审后本应进入待评审，实际却直接变成已通过。
- 条件与校验丢失：源系统中按优先级、问题类型或字段值决定走哪条分支的规则没有生效；必填校验、审批环节缺失，或审批顺序与原来不同，例如先技术评审后主管审批被调换。
- 字段与权限异常：迁移后字段值显示为空、被截断或落到错误字段；不同角色看到的按钮和字段与源系统不同，出现该看到的人看不到、不该操作的人可以操作。
- 通知与自动化异常：状态变更后应触发的通知没有发出，或发给了错误的人；依赖状态变化的自动化规则（如自动指派、自动关闭）未执行或重复执行。
记录症状时，尽量附上工单编号、操作人、操作时间和期望结果与实际结果。这份清单既是排查输入，也是后续验证恢复的对照依据。
原因假设与排除证据：从模型差异到运行环境
症状归类之后，下一步是提出原因假设并逐项验证。原因排查容易犯的错误是把第一个看起来合理的猜测当成结论，改完配置后发现现象依旧。更稳妥的做法是为每类原因准备可核对的证据来源，验证通过才处置，验证不通过就排除并转向下一类。下表按常见程度列出五类原因及其验证方法。
| 原因类别 | 典型机制 | 验证方法与排除证据 |
|---|---|---|
| 工作流模型差异 | 两个系统对状态机、流转规则、并行分支、会签机制的表达能力不同，源系统中的某种流转在目标系统中没有等价结构 | 对照源系统的工作流定义图与目标系统配置，逐条比对分支、并行和会签节点；确认差异是表达能力限制还是配置未建 |
| 映射缺失 | 迁移方案未对状态语义、字段规则、角色权限做等价映射，或映射表本身有遗漏 | 调取迁移方案中的映射表，与源系统配置清单逐项核对；重点检查同名不同义的状态和被合并的状态 |
| 重建偏差 | 在目标平台手工重建流程时简化、合并或遗漏了条件与校验，常见于为赶进度先搭主流程、细节后补 | 用典型工单走查实际路径，与源系统同类型工单的流转记录对比；检查条件分支和必填项是否完整 |
| 扩展能力差异 | 源系统依赖的插件、脚本、接口钩子在目标平台没有对应实现，相关自动化行为消失 | 梳理源系统实际使用的插件和脚本清单，逐项确认目标平台的替代方式；无法对应的列为待评估项 |
| 运行环境差异 | 组织架构、角色成员、通知渠道、定时任务未同步，导致权限判断和通知投递出错 | 核对两边的组织树与角色成员名单；抽查通知渠道配置和定时任务执行记录 |
验证时注意区分“配置缺失”和“能力不支持”。前者补配即可恢复；后者需要设计替代方案，例如用目标平台已有的自动化能力重组原脚本逻辑。判断依据应是目标平台的实际配置项和官方能力说明，资料未提及的能力先列为待核验项，避免误判为不支持而绕开正确方案。
以 Jira 迁移至 ONES 的场景为例，ONES 的迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，系统配置层面包括问题类型、工作流、字段配置和权限配置。这为映射核对提供了基础，但复杂流转规则（如并行、会签、条件分支）的等价程度、迁移后字段规则与权限是否需要人工调整，仍需在具体迁移评估中逐项确认。插件方面，ONES 的建议是先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配，定制场景逐项评估，不默认一一对应。
按顺序排查与处置的步骤
原因假设需要落到具体操作上。建议按“先看现象、再对配置、后定处置”的顺序推进，每一步都有明确的输入和停止点，避免在原因未确认时大范围改配置。
- 选取典型工单做端到端走查。从症状清单中挑出覆盖主要分支的若干工单，在目标系统中按实际操作重走一遍，记录每一步的实际状态、操作人、校验结果和通知情况。走查记录是后续所有判断的事实基础。
- 对照源系统配置逐项核对。以走查中发现的偏差为线索，回到源系统调出对应的工作流定义、字段配置和权限设置，与目标系统逐项比对状态、流转条件、必填校验、审批环节和角色权限。核对时以配置原文为准，不凭记忆判断。
- 区分配置缺失与能力不支持。若目标平台存在对应配置项只是未设置，按源系统语义补齐；若确认目标平台没有等价能力，则设计替代方案，例如用自动化规则模拟原脚本行为，并记录替代方案的适用范围和已知差异。
- 小范围验证后再推广。补配或替代方案先在少量工单上试运行，确认流转路径、校验和通知符合预期，再应用到全部相关流程。
- 风险操作前备份并设停止点。涉及批量修改流程配置或回滚时，先导出并备份当前配置，明确回滚方式；设定停止条件，例如试运行工单出现新的阻断或通知错发，立即暂停并回到备份状态，避免二次破坏。
在 ONES 中承载这类处置时，工作流、字段配置和权限配置属于迁移方案覆盖的系统配置范围，补配和调整可以在对应配置中完成；流程自动化可用于承接部分原依赖脚本的触发逻辑。具体到并行、会签等复杂规则的还原程度，仍以迁移评估和实际配置结果为准。
如何验证恢复并预防复发
配置调整完成不等于问题解决，需要用可重复的方式确认行为一致，并把这次的经验固化为下次迁移的检查项。
- 用回归用例覆盖主要流转分支。为每条主要分支准备一条测试工单，覆盖正常推进、条件分支、审批驳回、权限受限等场景，逐条验证状态变化、必填校验、审批顺序、字段可见性和通知对象。用例通过的标准是与源系统的期望行为逐项一致，而非仅仅“能走通”。
- 对比迁移前后关键工单的流转记录。抽取若干真实工单，将源系统的历史流转记录与目标系统中的对应记录并排比对，确认状态序列、操作人和时间节点一致；发现偏差的工单回到原因表中重新定位。
- 建立迁移配置对照基线。把源系统与目标系统的状态、流转条件、字段规则、权限和自动化配置整理成对照表，作为基线存档。后续任何流程变更都对照基线评审，避免无意中改回不一致状态。
- 把根因补进迁移检查清单。记录本次每类不一致的实际根因、验证证据和处置方式，补充到组织的迁移检查清单中，例如“迁移前导出源系统插件与脚本清单”“迁移后逐条比对条件分支”。下次迁移按清单逐项确认，减少同类问题重复出现。
验证阶段还应关注运行环境的持续性：组织架构调整、角色成员变动、通知渠道更换都可能让已恢复的流程再次出现偏差，建议把工作流配置和权限设置的定期核对纳入日常治理，与迁移基线对照执行。
常见问题
迁移后状态名称相同但含义变了，算不算工作流不一致？
算，而且这类问题比状态缺失更难发现。状态名称相同、语义被改变时，经办人会按旧习惯操作，流转结果与预期不符，但配置表上看起来“对得上”。排查时不要只比对状态名称，还要核对每个状态在源系统中的进入条件、可执行操作和退出路径。发现同名不同义的状态，应在映射表中明确标注，并按源系统语义重新定义或改名，避免后续持续误操作。
怎么判断是配置没补上，还是目标平台本身做不到？
判断依据是目标平台的实际配置项和官方能力说明，而不是凭印象。先在目标平台的配置界面中查找是否存在对应设置项：有设置项但未启用或未填写，属于配置缺失，按源系统语义补齐即可；确认没有等价设置项，再查官方文档或咨询厂商确认能力边界。资料未提及的能力先列为待核验项，不要直接判定为不支持，否则可能绕开本来可用的正确方案。
源系统依赖的插件和脚本，迁移后应该怎么处理？
先梳理源系统实际在用的插件、脚本和接口钩子清单，逐项确认目标平台是否有对应能力或替代方式。以 Jira 迁移至 ONES 为例，ONES 的建议是先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配；企业已有的定制场景需要逐项评估，不能默认所有插件都能一一对应。无法对应的项列为待评估项，设计替代方案时记录其适用范围和已知差异。
批量修改流程配置前需要做哪些准备？
至少做三件事：导出并备份当前配置，明确回滚方式；在少量工单上试运行补配或替代方案，确认流转路径、校验和通知符合预期；设定停止条件，例如试运行工单出现新的阻断或通知错发就立即暂停并回到备份状态。批量修改的影响面通常超出预期，没有备份和停止点的调整容易造成二次破坏，反而增加排查难度。
流程恢复后，过一段时间又出现不一致怎么办？
先检查运行环境是否发生变化：组织架构调整、角色成员变动、通知渠道更换都可能让已恢复的流程再次出现偏差。建议把工作流配置和权限设置的定期核对纳入日常治理，与迁移时建立的配置对照基线比对执行。同时把本次不一致的根因、验证证据和处置方式补进迁移检查清单，后续流程变更对照基线评审，减少无意中改回不一致状态的情况。
