工作流迁移要解决的是状态、流转条件、角色权限和通知规则在目标平台能否按原意运行。建议按“盘点来源工作流—建立状态与字段映射—小范围试迁移—逐项核验—分批切换并保留回退”推进，每一步都留下可核对的记录。本文以从Jira迁移到ONES为例说明操作细节，其他来源与目标平台可按同样顺序调整。
要点总览（TL;DR）
- 工作流迁移按“盘点来源工作流—建立状态与字段映射—小范围试迁移—逐项核验—分批切换并保留回退”推进，每一步都留下可核对的记录。
- 状态映射以含义、流转条件和角色权限是否一致为判定依据，分一对一、合并、拆分、废弃四种处理；字段映射分同名同义、同名异义、异名同义、目标缺失四类。
- 试迁移选一条代表性工作流加少量真实角色跑通典型路径，通过标准是流转可达、条件触发正确、权限无越界、通知无缺失。
- 核验按状态可达性、流转条件、角色权限、通知与自动化、看板与报表五类逐项检查，配置截图和业务负责人签字构成证据。
- 切换按团队或项目类型分批灰度，保留旧平台只读窗口，预设关键流转阻断、权限错配、通知大面积缺失等回退触发条件。
来源与目标：先界定迁移哪些工作流
迁移开始前，先把“迁移什么”写清楚。工作流迁移的对象是行为规则，包括状态机、流转条件、审批节点、角色权限、通知和自动化触发；历史记录数据的批量搬运与清洗属于另一项工作，需要单独安排。两者混在一起，容易在试迁移阶段把配置问题和数据问题搅在一起，难以定位。
来源侧要记录平台名称、版本和工作流的承载方式。以Jira为例，工作流通常绑定在项目的问题类型上，同一状态名在不同项目里可能有不同流转路径。目标侧同样要记录版本和配置入口。ONES的Jira迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，其中问题类型、工作流、字段配置、权限配置属于系统配置迁移范围，具体可迁移项需按来源配置逐项核对。
范围清单建议包含以下字段，逐条填写后再进入映射：
| 清单项 | 填写内容 | 示例 |
|---|---|---|
| 来源平台与版本 | 产品名、版本号、工作流承载位置 | Jira，工作流绑定在项目的问题类型上 |
| 目标平台与版本 | 产品名、版本号、配置入口 | ONES Project，项目模板与工作项配置 |
| 纳入迁移的工作流 | 项目类型、状态机、流转条件、角色权限、通知、自动化 | 需求类工作流：待评估→开发中→测试中→已上线 |
| 排除项 | 历史记录数据搬运、上线后日常配置治理 | 历史工单正文与附件的批量导入另行立项 |
| 版本基线 | 来源配置的导出时间或截图时间 | 2026年3月导出的工作流配置 |
排除项要显式写出，避免执行中反复扩大范围。上线后的状态增删、字段调整属于日常配置治理，迁移阶段只保证切换时点的行为一致。
本阶段输入与依赖：迁移前要备齐什么
映射和试迁移能否顺利，取决于前置材料是否完整。来源侧需要拿到状态列表、每条流转的触发条件、条件表达式原文、审批节点设置、角色与字段配置。导出文件优先，无法导出时用配置截图加文字说明，截图要包含配置入口和生效范围，便于后续核对。
目标侧的前置准备包括：建好项目模板，导入或创建成员并分配角色，配置工作流需要的自定义字段。字段类型要先定下来，例如日期、单选、人员，类型不一致会导致映射阶段反复返工。
角色分工建议按三类人安排，并在迁移启动会上确认：
- 业务负责人：确认状态含义、流转条件和审批规则，对“同名不同义”的判定签字。
- 平台管理员：在目标平台执行配置，负责模板、状态、字段、权限和通知的设置。
- 测试人员：按典型路径执行试迁移，记录差异，不参与规则解释，保证核验独立。
三类角色之外，还需要一位协调人跟踪差异清单的关闭状态。差异项积压到切换前才处理，往往只能靠临时放宽权限或跳过条件来赶进度，这会削弱后续核验的可信度。
状态与字段映射：同名不同义怎么处理
映射的判定依据是状态含义、流转条件和角色权限是否一致，名称相同只是线索。来源和目标都有“已完成”，但来源的“已完成”允许测试人员直接置入，目标的“已完成”只允许项目经理操作，这就是两个不同的状态，需要按差异处理。
状态映射有四种处理方式：
- 一对一：含义、进入条件、可操作角色都一致，直接对应。
- 合并：来源两个状态在业务上已无区分必要，例如“待验证”和“待测试”，合并后要确认历史流转路径不受影响。
- 拆分：来源一个状态在目标侧需要按条件分成两个，例如“处理中”按问题类型拆成“开发中”和“设计中”，拆分后要补写各自的流转条件。
- 废弃：来源状态已停用或仅存于历史数据，登记为不迁移，并在映射表中注明原因。
字段映射按四类情形处理。同名同义直接对应；同名异义要改目标字段名或加说明，避免使用者按旧含义填写；异名同义做名称对应并保留来源名称备查；目标缺失的字段先登记为遗留问题，评估是否用现有字段承载或新增字段，不直接删除。
| 来源对象 | 目标对象 | 映射类型 | 差异说明 | 确认人 |
|---|---|---|---|---|
| 状态“待验证” | 状态“待测试” | 合并 | 来源两个状态由不同角色操作，合并后统一为测试负责人 | 业务负责人 |
| 字段“优先级” | 字段“紧急度” | 异名同义 | 取值档位一致，目标侧名称不同 | 平台管理员 |
| 字段“客户编号” | 无对应字段 | 目标缺失 | 登记遗留问题，评估新增自定义字段 | 业务负责人 |
| 流转条件“仅报告人可关闭” | 权限配置：关闭操作限定报告人角色 | 条件转权限 | 来源用条件表达式，目标用角色权限实现 | 平台管理员 |
流转条件和角色权限要逐条对应写法。条件表达式在目标平台可能没有等价语法，需要用审批节点或角色权限替代，替代后要验证效果是否一致。ONES支持迁移Jira的问题类型、工作流、字段配置和权限配置，条件表达式与自动化规则的具体映射能力需在试迁移中逐项验证，不能默认全部等价。依赖插件的功能，ONES的建议是先梳理实际使用的插件，再通过项目、Wiki、TestCase、流程自动化和开放能力做功能匹配，定制场景逐项评估。
试迁移：选一条工作流跑通全流程
试迁移的目的是用最小成本暴露映射错误。样本选择一条代表性工作流，覆盖状态数量中等、包含至少一个条件流转和一个审批节点，再配少量真实角色，例如报告人、处理人、审批人各一名。样本太大，差异难以归因；样本太小，条件与权限问题暴露不出来。
执行按以下顺序进行：
- 在目标平台建项目模板，按映射表配置状态和流转路径。
- 设置流转条件、审批节点、字段必填规则和通知。
- 分配角色权限，确认每个角色能看到和操作的范围。
- 用真实角色走一遍典型路径，从创建到关闭，中途触发一次条件流转和一次审批。
- 记录每一步的实际结果与预期结果的差异。
差异记录要具体到现象，例如“处理人提交测试时流转按钮不可见”“审批通过后通知未发给报告人”“测试角色可以跳过审批直接关闭”。这些现象分别指向条件配置、通知规则和权限设置，便于管理员定点修正。
试迁移的通过标准可以定为：典型路径全程可达，条件流转按预期触发或阻断，角色权限无越界，通知在关键节点送达。任一项不通过，先修正配置再重跑同一路径，不通过时不进入全面核验。
核验与证据：怎么判断迁移到位
试迁移解决“能不能跑通”，核验解决“是否每条规则都到位”。核验按工作流逐条进行，核验项固定为五类：状态可达性、流转条件触发、角色权限、通知与自动化、看板与报表呈现。每类都写成可执行的检查动作，而不是笼统的“检查配置”。
| 核验项 | 检查动作 | 证据形式 |
|---|---|---|
| 状态可达性 | 从初始状态按每条合法路径走到终态，确认无断路 | 路径截图、测试用例执行记录 |
| 流转条件触发 | 分别用满足和不满足条件的角色操作，确认阻断生效 | 操作截图、条件配置截图 |
| 角色权限 | 用每个角色登录，核对可见范围与可操作项 | 权限配置截图、角色核对表 |
| 通知与自动化 | 触发关键节点，确认通知对象和内容正确 | 通知截图、触发记录 |
| 看板与报表 | 确认状态在视图中的分组和统计口径一致 | 视图截图、口径说明 |
证据按工作流归档，配置截图要带时间和配置入口。业务负责人对核验结果签字确认，签字范围写明覆盖的工作流和角色。未通过项登记为遗留问题，记录现象、影响范围、责任人和计划关闭时间；影响关键流转的遗留问题在关闭前不进入切换。
在ONES侧执行这类核验时，状态、字段和权限配置可以在项目配置中逐项对照，试迁移和核验记录建议与映射表放在同一份文档中，便于切换阶段回溯。
切换与回退：分批上线和停止条件
切换按批次进行，批次划分可以按团队或项目类型，优先选择试迁移已覆盖、规则相对简单的团队。每批切换后保留旧平台只读窗口，窗口长度按业务节奏确定，期间旧平台不再接受新操作，只用于查询和对照。ONES的迁移方案把迁移工具、原厂服务和分阶段切换结合，并在正式迁移前确认数据范围、功能匹配和系统适配，批次计划应与此保持一致。
回退触发条件要在切换前写明，常见的有三类：关键流转阻断导致业务无法推进、角色权限错配导致越权或无法操作、通知大面积缺失导致审批停滞。触发后按预案执行：恢复旧平台写入、回滚目标平台本批配置、保留差异记录供下一批修正。回滚前先确认本批已产生的数据如何处理，避免两边状态不一致。
以下情形应暂停扩大迁移范围：来源规则无法确认，例如原负责人已离职且无文档；目标能力未验证，例如条件表达式或自动化规则在试迁移中未跑通；遗留问题中有影响关键流转的未关闭项。暂停不等于终止，补齐输入或完成验证后再评估下一批。
整个迁移过程以“数据完整、业务连续、系统稳定”为目标，具体部署形态和合规要求按项目实际确认。按盘点、映射、试迁移、核验、分批切换的顺序推进，每一步都有记录和回退点，工作流迁移的可控性来自这些可核对的环节，而非一次配置到位。
常见问题
来源工作流里用条件表达式控制流转，目标平台没有等价语法怎么办？
先判断这条条件的实际作用：限制谁能操作、限制在什么状态下操作，还是限制字段取值。作用在“谁能操作”上的条件，通常可以改写成目标平台的角色权限；作用在“什么状态或字段取值”上的条件，可以尝试用审批节点或必填规则承载。改写后要在试迁移中验证效果一致，例如用不满足原条件的角色操作一次，确认流转被阻断。
如果一条条件同时承担多种作用，建议拆成多条规则分别配置，便于核验时定位。改写方案和验证结果都记入映射表的差异说明，由业务负责人确认。
迁移过程中发现来源工作流的规则没人说得清，还能继续吗？
这类工作流应暂停迁移，不进入下一批。常见原因是原负责人已离职、规则只存在于口头约定，或配置与文档不一致。处理方式有两种：一是由现任业务负责人根据近期实际流转记录反推规则并书面确认；二是将该工作流登记为遗留项，先迁移规则清晰的部分。
在规则确认前扩大迁移范围，会把不确定性带到目标平台，后续核验也缺少判定基准。暂停不等于终止，补齐输入后再评估。
试迁移通过了，全面核验还需要逐条工作流做吗？
需要。试迁移验证的是一条代表性工作流能否跑通，核验要覆盖每条纳入迁移的工作流。两者检查深度不同：试迁移侧重暴露配置错误，核验侧重确认每条规则到位并留下证据。
核验可以按工作流分组安排，同一模板下规则相同的项目可共用一份核验记录，但状态可达性和角色权限仍需按实际角色逐一确认。影响关键流转的遗留问题在关闭前不进入切换。
分批切换时，旧平台只读窗口要留多久？
窗口长度按业务节奏确定，没有统一标准。判断依据是本批团队完成一个完整业务周期所需的时间，以及切换后出现问题时需要多久才能定位。窗口期内旧平台不再接受新操作，只用于查询和对照，避免两边同时产生数据导致状态不一致。
窗口结束前要确认本批遗留问题已关闭或已明确处理计划，并完成旧平台写入权限的回收。
回退之后，本批已经在新平台产生的数据怎么处理？
回退前先确认本批数据的处置方式，再执行回滚。常见做法是保留新平台本批产生的记录作为差异样本，供修正配置后重新验证；业务操作恢复到旧平台继续。两边状态不一致的部分要逐条登记，写明来源、差异和后续处理人。
回滚目标平台配置时，先导出当前配置留档，再恢复到切换前版本，避免修正过程中丢失已做的调整。
