工作流迁移的核心，是把源平台的工作流拆成可核对的结构：触发条件、状态与流转规则、字段与权限、通知与自动化动作、扩展脚本或集成。先盘点范围并建立映射表，再用真实工单做小范围试迁移，确认状态流转与通知结果后再分批切换，并保留可回退的旧流程一段时间。迁移方向是源到目标，字段含义不同的部分要逐项确认，同名不代表等价。
要点总览（TL;DR）
- 工作流迁移先界定源平台、目标平台和迁移对象，把状态、流转条件、字段、权限、通知、自动化动作列为行为迁移范围，历史记录搬运与目标平台日常治理另行处理。
- 映射以条目为单位逐项对照，同名不同义字段回到定义、取值范围和业务用途确认，无法直接映射的项明确降级、替代或放弃并记录决策人。
- 用两到三条代表性工作流和真实工单做试迁移，跑通关键路径与异常路径，把偏差回写映射表后再进入全量核验。
- 验收按状态流转、字段、权限、通知与自动化四组逐项核对，以截图、对照表和签字确认作为通过证据。
- 切换按优先级分批推进并保留并行期，提前写定回退触发条件和回退操作，旧流程至少覆盖一个完整业务周期再下线。
迁移范围：哪些工作流行为需要搬过去
迁移开始前先写清三件事：从哪个平台的哪个版本迁到哪个平台的哪个版本、涉及哪些团队或项目、本次迁移包含哪些工作流行为。范围清单是后续所有工作的基准，范围不清会导致映射表反复返工。
工作流清单建议按项目或团队分组，逐条标注优先级。优先级可以按业务影响判断：阻塞研发主流程的缺陷流转、需求评审流转排在前，低频的行政审批类流程可以排后或本次不迁。每条工作流记录名称、使用团队、月均实例量、关联的自动化规则数量，这些信息决定试迁移的抽样对象和切换顺序。
需要明确区分三类内容。第一类是工作流行为迁移，包括状态定义、流转条件、必填校验、权限控制、通知规则和自动化动作。第二类是记录数据搬运，即历史工单及其字段值的批量导入，这部分涉及字段清洗和值转换，属于另一项工作，本文不展开。第三类是目标平台的日常配置与治理，例如新建流程规范、权限审批制度，迁移只负责把源流程落到目标平台，不重新设计治理体系。
范围清单还应写明本次不迁移的项及理由，例如某个依赖定制脚本的审批流改为人工处理、某个已停用的旧流程直接归档。排除项写清楚，验收时才不会出现“以为要迁”的争议。
| 清单字段 | 填写内容 | 示例 |
|---|---|---|
| 源平台与版本 | 平台名称、版本、部署方式 | 源平台 A，版本待确认，私有部署 |
| 目标平台与版本 | 平台名称、版本、项目空间 | 目标平台 B，研发项目空间 |
| 工作流名称 | 源平台中的流程名称 | 缺陷处理流程 |
| 使用团队 | 实际使用该流程的团队 | 客户端组、服务端组 |
| 优先级 | 高/中/低 | 高 |
| 迁移结论 | 迁移/降级/放弃 | 迁移 |
| 排除说明 | 不迁移的原因 | — |
迁移前要准备哪些输入
映射工作依赖源侧材料齐全。缺少源工作流的准确描述，映射表只能靠记忆填写，试迁移阶段必然暴露大量偏差。启动前按下表逐项确认输入是否到位，并指定每项输入的提供人和确认人。
| 输入项 | 内容要求 | 提供人 | 确认人 |
|---|---|---|---|
| 源工作流说明 | 状态机图或截图、每个状态的进入与退出条件、流转规则文字说明 | 源平台管理员 | 流程负责人 |
| 字段字典 | 字段名称、类型、取值范围、是否必填、业务含义 | 源平台管理员 | 业务代表 |
| 权限角色对照 | 源平台角色、角色对应的操作权限、人员名单 | 源平台管理员 | 团队负责人 |
| 自动化与集成清单 | 触发器、执行动作、调用的外部系统、脚本位置 | 平台管理员或开发 | 技术负责人 |
| 目标平台可配置项 | 支持的状态类型、流转条件写法、字段类型、权限模型、自动化能力 | 目标平台管理员 | 迁移负责人 |
| 目标平台限制 | 状态数量上限、字段类型限制、脚本执行条件等 | 目标平台管理员 | 迁移负责人 |
目标平台可配置项与限制的确认方式，建议由目标平台管理员在测试空间中实际配置一遍再回复，而不是只查文档。文档描述与实际版本行为可能有差异，实际配置能提前暴露限制。对于从 Jira 迁移到 ONES Project 的场景，ONES 的迁移方案覆盖项目、系统配置（含问题类型、工作流、字段配置、权限配置等）、用户与用户组，实际可迁移项以迁移前评估为准，因此输入清单中的源侧材料仍需完整准备，用于核对迁移结果。
责任人分工要落到具体人名，并约定材料提交的截止时间。确认人负责判断材料是否足以支撑映射，材料不齐不进入映射阶段。
工作流结构与字段的映射方法
映射的基本单位是条目，不是整条流程。把每条源工作流拆成状态、流转条件、必填字段、权限、通知、自动化动作六类条目，逐条在目标平台找对应配置，逐条给出结论。整条流程笼统对照，问题会被掩盖到试迁移阶段才暴露。
状态映射先对齐语义再对齐名称。源平台的“已解决”和目标平台的“已完成”可能承担相同职责，也可能源平台的“已解决”还包含待验证环节。判断依据是状态前后的流转关系：谁在什么条件下把工作项推进到该状态，进入后触发什么动作。流转条件逐条翻译为目标平台的条件表达式，涉及角色判断、字段值判断、时间条件的，要确认目标平台是否支持同等表达。
同名不同义字段是映射中最容易出错的部分。处理方法是回到字段定义、取值范围和业务用途三项逐一比对。例如源平台和目标平台都有“优先级”字段，但源平台取值为五级、目标平台为三级，就需要确定降级规则并记录；两个平台都有“模块”字段，但源平台按代码仓库划分、目标平台按产品线划分，含义不同，应视为两个字段分别映射，不能直接对应。判定结论写入映射表，注明“等价”“近似”“需转换”“无对应”四种状态之一。
无法直接映射的项要给出明确处理方式：降级为近似能力、用替代方式承接、或本次放弃。每种处理都记录决策人和理由。涉及插件或扩展脚本的场景尤其需要逐项评估。ONES 的迁移方案建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配；企业已有的定制场景在迁移前仍需逐项评估，避免假设所有插件都能一一对应。
| 映射表字段 | 填写规则 | 示例 |
|---|---|---|
| 条目编号 | 流程缩写加序号 | BUG-03 |
| 条目类型 | 状态/流转条件/字段/权限/通知/自动化 | 字段 |
| 源配置 | 名称、类型、取值、规则原文 | 优先级，五级单选，必填 |
| 目标配置 | 对应名称与配置方式 | 优先级，三级单选，必填 |
| 映射结论 | 等价/近似/需转换/无对应 | 需转换 |
| 转换规则 | 取值对应关系或处理方式 | 最高→高，高与中→中，低与最低→低 |
| 决策人与理由 | 姓名与判断依据 | 张某，按业务影响合并 |
试迁移：小范围验证映射结果
试迁移的目的是用少量真实流程检验映射表，而不是提前上线。选取两到三条代表性工作流，覆盖高频主流程和一条含自动化动作的流程，再从源平台取若干真实工单作为样本，样本应包含正常流转的工单和发生过退回、跳转的工单。
在目标平台按映射表重建流程，然后跑通关键路径与异常路径。关键路径指工单从创建到关闭的主干流转；异常路径指退回、重新打开、跨状态跳转、权限不足被拦截等情形。每一步记录实际结果与映射表预期的差异，重点看四类偏差：状态跳转是否按条件触发、通知是否发给正确的人、权限是否按角色生效、自动化动作是否执行且结果正确。
偏差分两种处理。映射表填写错误的，直接回写修正；目标平台能力与源平台存在差异的，记录差异并调整处理方式，例如把自动指派改为规则触发后由负责人手动确认。试迁移结束后，映射表中每条被验证的条目标注验证状态，未覆盖的条目列入后续核验重点。
试迁移记录建议包含：样本工单编号、执行的路径、预期结果、实际结果、偏差类型、修正动作、修正后复测结果。这份记录同时是验收阶段的证据来源。
核验与证据：怎么判断迁移通过
迁移通过的标准是逐项核对后关键路径与异常路径均符合映射表预期，并有确认记录。核验不是抽查，而是按核对表逐条打勾，每条核对项对应映射表中的条目编号，形成可追溯的对应关系。
核对项分四组。状态与流转组核对每个状态的进入条件、退出条件、跳转限制；字段组核对字段类型、必填规则、默认值、取值范围；权限组核对各角色在各状态下的可见与可操作范围；通知与自动化组核对触发时机、接收对象、执行结果。每组都要覆盖关键路径和至少一条异常路径。
比对方法以源目标并排对照为主：同一操作在源平台和目标平台各执行一次，截图记录结果，填入对照表。通知类核对以实际收到的消息为准，记录接收人和内容。自动化动作核对执行日志或结果字段的变化。
| 核对项 | 核对方法 | 证据形式 | 结论 |
|---|---|---|---|
| 状态流转条件 | 按条件逐条触发，观察是否允许或拦截 | 操作截图与对照表 | 通过/不通过 |
| 必填字段校验 | 留空提交，观察是否拦截 | 截图 | 通过/不通过 |
| 角色权限 | 用不同角色账号执行同一操作 | 账号与结果对照表 | 通过/不通过 |
| 通知接收人 | 触发流转，核对实际接收人 | 消息截图 | 通过/不通过 |
| 自动化动作 | 触发规则，核对执行结果 | 执行记录截图 | 通过/不通过 |
证据归档按工作流分目录存放，包含映射表终版、试迁移记录、核对表、截图和确认记录。通过标准建议设为：所有高优先级工作流的核对项全部通过，中低优先级工作流的不通过项已有明确处理结论并经确认人签字。签字确认由流程负责人和迁移负责人共同完成，确认记录注明日期和覆盖范围。
切换节奏与回退条件
切换采用分批方式，顺序与范围清单中的优先级一致：先切一条高优先级流程到小范围团队，观察一段时间后再扩大团队范围，最后处理中低优先级流程。每批切换前确认该批工作流的核验已通过，切换后保留一段并行期，旧流程只读或仅处理存量工单，新工单进入目标平台。
回退触发条件要在切换前写定，常见的有：关键路径无法走通且短时间内无法修复、权限配置导致部分角色无法操作、通知大面积错发或漏发影响业务响应、自动化动作产生错误结果且无法快速回滚。触发条件满足时停止该批次的继续推广，按预案回退到旧流程处理新工单。回退操作包括恢复旧流程的写入权限、通知团队切换回旧入口、冻结目标平台该流程的新建工单，具体步骤由目标平台管理员执行并记录。
旧流程保留时长按业务周期确定，建议至少覆盖一个完整的业务周期，确认目标平台运行稳定、无遗漏工单后再下线。下线条件包括：并行期内新平台无阻断性问题、存量工单处理完毕、团队确认不再需要旧入口。切换后的观察项包括状态流转是否顺畅、通知是否按时送达、自动化动作是否按预期执行、用户反馈的操作障碍。ONES 的建议是把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配，以降低迁移过程中数据丢失或业务中断的风险；具体实施安排需结合企业实际情况确定。
常见问题
源平台的工作流文档不全，映射还能不能启动？
可以先启动，但要把补齐材料作为映射的前置条件。至少需要拿到状态机图或截图、每个状态的进入与退出条件、字段字典和权限角色名单；缺少这些内容时，映射表只能靠记忆填写，试迁移阶段会集中暴露偏差。实际操作中可以让源平台管理员在测试环境里逐条走一遍流程并录屏，作为说明材料的补充。材料补齐前，建议只做范围盘点和优先级排序，不进入逐条映射。
试迁移要选多少条工作流、多少工单才算够？
数量没有统一标准，判断依据是覆盖度。工作流层面建议覆盖一条高频主流程和一条含自动化动作的流程；工单层面要包含正常流转的样本，也要包含发生过退回、重新打开或跨状态跳转的样本。如果某条流程的流转条件涉及多角色判断，样本中应包含不同角色账号的操作记录。试迁移的目标是暴露映射错误，样本覆盖不到的条目要在核验阶段列为重点核对项。
迁移过程中发现目标平台不支持源平台的某个流转条件，怎么处理？
先确认差异的具体范围：是条件表达方式不同，还是该能力在目标平台不存在。表达方式不同的，改写为目标平台支持的条件组合；能力缺失的，给出三种处理之一并记录决策人和理由：降级为近似规则、改为人工确认环节承接、本次放弃该条件。处理结论要回写映射表，并在试迁移中验证替代方案的实际效果。涉及插件或扩展脚本的场景，建议先梳理实际使用的插件清单，再逐项做功能匹配，避免假设所有插件都能一一对应。
切换后出现什么问题应该触发回退？
回退触发条件要在切换前写定，常见情形包括：关键路径无法走通且短时间内无法修复、权限配置导致部分角色无法操作、通知大面积错发或漏发影响业务响应、自动化动作产生错误结果且无法快速回滚。触发后停止该批次继续推广，恢复旧流程的写入权限，通知团队切回旧入口，并冻结目标平台该流程的新建工单。回退操作由目标平台管理员执行并留记录，问题修复后重新走核验再切换。
旧流程要保留多久才能下线？
按业务周期确定，建议至少覆盖一个完整的业务周期。下线前确认三件事：并行期内目标平台没有出现阻断性问题、存量工单已处理完毕、团队确认不再需要旧入口。保留期间旧流程设为只读或仅处理存量工单，新工单进入目标平台，避免两边同时写入造成状态不一致。下线操作同样要记录时间和范围，便于后续追溯。
