工作流与扩展能力迁移，核心是把源平台的状态机、流转规则、自动化触发和扩展脚本逐项盘点，映射成目标平台可承载的等价配置，再通过试迁移和抽样核验确认行为一致。操作顺序是：划定迁移范围与源目标版本，建立工作流与扩展能力清单，逐条做字段与规则映射，选一条低风险流程试迁移并对比行为，最后分批切换并保留回退路径。本文以从 Jira 迁移到 ONES 为例说明方法，其他源平台可参照同一流程调整。
要点总览（TL;DR）
- 迁移范围先切分清楚：工作流状态机、流转条件、审批节点、自动化规则、脚本、Webhook 和字段联动属于行为迁移；历史工单记录搬运归数据迁移，上线后的日常配置调整归配置治理。
- 工作流映射以状态对应表为基础，逐条记录源配置、目标配置、等价程度和待确认项；审批会签等无法等价表达的场景要写明降级方案。
- 扩展能力按自动化规则、脚本、Webhook、外部集成的顺序逐条映射，先梳理实际使用清单，再判断直接配置、改写还是替代。
- 选一条低风险流程试迁移，用同一操作在源目标两端的表现差异记录问题，回改后再进入抽样核验。
- 分批切换前明确每批的进入条件、停止条件和回退动作，切换期间并行运行并保留旧平台一段时间。
迁移范围：哪些工作流与扩展能力要迁
迁移开始前先写清三件事：源平台与目标平台的名称及版本、纳入迁移的工作流类型、纳入迁移的扩展能力类型。范围清单越具体，后续映射和核验越容易对齐。以 Jira 迁移到 ONES 为例，源平台版本要记录到具体大版本，目标平台要记录当前使用的产品与版本，因为不同版本对工作流和自动化的支持范围可能不同。
纳入迁移的工作流通常按业务对象划分：需求、缺陷、任务、审批各有自己的状态机和流转规则，需要分别列出。扩展能力按类型列出：状态机与状态类别、流转条件（角色、字段值、权限）、自动化规则、脚本类扩展、Webhook、字段联动。每一类都标注数量和使用频率，使用频率高的优先迁移。
范围清单同时要写排除项。历史工单与记录的批量搬运属于数据迁移，不在本文范围内；目标平台上线后的日常配置调整属于平台配置治理，也不在本阶段展开。把这两类切分出去，可以避免行为迁移被数据量问题拖慢，也避免把上线后的常规优化混进迁移验收。
| 范围项 | 纳入内容 | 排除内容 |
|---|---|---|
| 工作流 | 需求、缺陷、任务、审批的状态机与流转规则 | 历史工单记录的批量搬运 |
| 扩展能力 | 自动化规则、脚本、Webhook、字段联动、权限配置 | 上线后的日常配置治理 |
| 版本 | 源平台与目标平台的具体版本 | 未确认的版本兼容性结论 |
迁移前的输入与依赖盘点
映射开始前需要拿到源平台的完整配置输入。常见获取方式有三种：管理后台导出配置文件、逐屏截图并编号、由原厂或实施方提供配置清单。无论哪种方式，都要保证输入可追溯，能对应到具体项目和工作流。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并支持迁移问题类型、工作流、字段配置、权限配置等系统配置，实际可迁移项仍需按源端配置逐项核对。
目标平台的能力边界要提前确认。工作流能配置几级状态、流转条件支持哪些判断维度、自动化支持哪些触发与动作、开放接口提供哪些能力，这些决定了映射时哪些可以等价表达、哪些需要降级。ONES 提供流程自动化和 API / Webhook 开放能力承接集成与扩展场景，具体接口范围和限制需按目标平台文档核验。
角色与权限同样要列进依赖清单。平台管理员负责配置导入与权限设置，流程负责人确认业务规则是否等价，业务代表在试迁移阶段实际操作并反馈差异。每项输入标注负责人和获取方式，形成一张可跟踪的表。配置修改权限和验收确认权限建议分开，避免同一人既改配置又判定通过。
- 源平台配置导出文件或截图清单，标注对应项目与工作流
- 目标平台工作流、自动化与开放能力的能力说明
- 平台管理员、流程负责人、业务代表的名单与职责
- 配置修改与行为确认的权限分配
工作流状态与流转规则的映射方法
工作流映射从状态对应表开始。把源平台的每个状态映射到目标平台的状态，并标注状态类别（待处理、进行中、已完成等）。状态名称可以不同，但状态类别决定看板分组、报表统计和自动化判断，必须逐条确认。建议表格包含四列：源状态、目标状态、状态类别、等价程度。
流转条件是映射中最容易出偏差的部分。源平台用角色、字段值、权限组合控制谁能把工作项从 A 状态推到 B 状态，目标平台可能用不同的表达方式实现同样效果。逐条记录源条件、目标条件、验证方式。同名字段含义不同时，以业务含义为准重新命名或增加说明，不能因为字段名相同就直接对应。
审批节点和多人会签要单独处理。源平台的多级审批、会签、或签规则，在目标平台可能需要拆成多个节点或借助自动化实现。无法等价表达时，记录降级方案：例如把会签简化为指定角色审批，并在映射表中标注影响范围和待确认项。ONES 可迁移 Jira 的工作流与字段配置，状态机与审批节点的具体配置能力边界需在实施时按目标平台文档核验。
| 映射项 | 源配置 | 目标配置 | 等价程度 | 待确认项 |
|---|---|---|---|---|
| 状态 | 待办 / 处理中 / 已完成 | 待处理 / 进行中 / 已完成 | 等价 | 状态类别是否一致 |
| 流转条件 | 项目角色为开发才能流转 | 按角色配置流转权限 | 需验证 | 角色映射是否完整 |
| 审批节点 | 两级会签 | 拆分节点或自动化 | 降级 | 会签语义是否保留 |
| 字段联动 | 选择类型后显示子字段 | 按字段配置联动 | 需验证 | 联动触发时机 |
扩展能力的迁移：自动化、脚本与集成
扩展能力按“先清单、再映射、后验证”的顺序处理。第一步梳理实际在用的自动化规则、脚本、Webhook 和外部集成，标注每条规则的触发条件、执行动作和影响对象。第二步逐条判断目标平台能否直接配置、需要改写还是需要替代方案。第三步为每条扩展写明验证方法，例如触发一次测试事件观察结果。
自动化规则的映射要区分触发条件和动作。触发条件包括状态变更、字段更新、时间条件等，动作包括通知、字段赋值、状态流转、创建关联工作项等。源平台的一条规则在目标平台可能需要拆成多条，或者用不同的触发方式实现。ONES 提供流程自动化能力承接常用插件场景，具体支持的触发条件与动作类型需逐项确认。
脚本类扩展通常无法直接搬运，需要改写或替代。处理路径有三条：用目标平台的自动化配置替代脚本逻辑；通过开放接口实现同等效果；保留外部服务承接脚本并重新对接。选择哪条路径取决于脚本的复杂度和调用频率。ONES 迁移方案建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配，定制场景迁移前仍需逐项评估。
Webhook 与外部集成的迁移重点是重连和验证。迁移后要重新配置回调地址、鉴权方式和事件订阅，然后触发测试事件确认外部系统能正常接收。ONES 提供 API / Webhook 开放能力支撑迁移后的集成场景，接口范围、调用限制与版本兼容性需按目标平台文档核验。扩展能力在目标平台不可用时，记录替代方案和影响范围，作为切换决策的输入。
| 扩展类型 | 迁移方式 | 替代方案 | 验证方法 |
|---|---|---|---|
| 自动化规则 | 逐条映射触发与动作 | 拆分或合并规则 | 触发测试事件观察结果 |
| 脚本 | 改写或外部承接 | 用自动化或开放接口替代 | 对比输入输出结果 |
| Webhook | 重配回调与鉴权 | 调整事件订阅范围 | 触发事件确认接收 |
| 外部集成 | 重新对接 | 更换集成方式 | 端到端联调 |
试迁移：选一条流程跑通全链路
试迁移选一条使用频率适中、参与角色不多、不涉及关键对外集成的流程。选取标准是：流程完整覆盖状态流转、条件判断和至少一条自动化规则，出问题时影响可控。缺陷处理或内部任务流程通常比需求审批更适合作为第一条试迁移流程。
执行步骤按角色分工推进：平台管理员导入配置，流程负责人核对状态与流转条件，业务代表按真实操作路径走一遍。每一步记录操作内容、预期结果和实际结果。同一操作在源平台和目标平台各执行一次，对比状态变化、通知发送、字段更新和权限可见性是否一致。
发现差异后走回改流程：记录差异、判断是映射错误还是目标平台能力限制、修改配置或调整降级方案、重新执行对比。试迁移记录要包含选取流程、执行步骤、差异清单和回改结论，作为后续批次切换的参考。ONES 迁移方案把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配，试迁移正是这一确认过程的落地方式。
核验与证据：怎么确认迁移后行为一致
核验围绕四类行为展开：状态流转是否按规则执行、权限可见性是否符合预期、自动化是否在正确时机触发、通知与集成回调是否送达。每类行为列出具体核验项，逐项标注通过状态和证据位置。核验通过的标准是实际表现与映射表中记录的预期一致，而不是凭操作人员的主观感觉。
抽样核验的样本要覆盖不同状态、不同角色和不同触发条件。建议按工作流类型分层抽样，每条工作流至少抽取若干条记录，覆盖正常流转、条件不满足被拦截、自动化触发三类场景。样本选取方法和抽样比例写进核验清单，便于复核。
证据形式包括配置对比截图、操作日志和测试用例结果。配置对比截图证明源目标配置的对应关系，操作日志证明实际行为发生，测试用例结果证明预期结果达成。核验不通过时，判定标准要提前写明：关键流程状态流转错误、权限越权可见、自动化未触发或集成回调失败，任一项出现即判定该批次不通过，回到映射或配置环节修正。
- 状态流转：逐状态验证流转路径与拦截条件
- 权限可见性：按角色验证可见范围与操作权限
- 自动化触发：按触发条件验证动作执行结果
- 通知与集成回调：验证消息送达与外部系统接收
分批切换与回退条件
分批切换按业务影响从低到高排列批次。第一批选试迁移验证过的流程类型，第二批扩展到同类其他项目，后续批次覆盖审批类和涉及外部集成的流程。每批切换前明确进入条件：该批流程的映射表完成、试迁移或抽样核验通过、回退方案就绪。批次划分依据是流程复杂度、集成依赖和用户范围，不按部门平均分配。
切换期间安排并行运行。旧平台保留读写权限一段时间，新平台承接新产生的工作项，旧平台的历史记录保持可查。并行期的长度取决于业务节奏和核验进度，建议以完成一轮完整业务周期为准。并行期间指定专人收集差异反馈，按回改流程处理。
停止条件要写进切换计划：关键流程行为不一致且无法在计划时间内修正、外部集成中断影响业务、权限异常导致数据越权可见，出现任一项即暂停该批次推进。回退路径包括配置回滚和旧平台保留期限，回滚操作要提前演练，确认配置能恢复到切换前状态。ONES 迁移方案支持分阶段切换，具体批次划分与回退机制需结合企业实际排期确定。
| 批次 | 进入条件 | 停止条件 | 回退动作 |
|---|---|---|---|
| 第一批 | 试迁移通过、映射表完成 | 状态流转错误未修正 | 恢复旧平台配置 |
| 第二批 | 抽样核验通过、并行运行稳定 | 权限异常或集成中断 | 暂停切换并回滚配置 |
| 后续批次 | 前批核验通过、回退预案就绪 | 关键流程行为不一致 | 按预案回退并复盘 |
常见问题
源平台的工作流配置拿不到导出文件，只有截图，还能做迁移映射吗？
可以，但要把截图整理成可追溯的清单。按项目和工作流编号，每张截图标注对应的状态机、流转条件或自动化规则，再由流程负责人逐条确认截图是否反映当前实际配置。截图方式的局限在于看不到配置之间的引用关系，例如某个流转条件引用了哪个角色或字段，这类依赖需要额外向原平台管理员确认。整理完成后，映射表的“源配置”一列以截图编号加文字描述为准，避免后续核验时对不上。
目标平台无法等价表达源平台的会签或多级审批，应该怎么处理？
先判断业务上是否真的需要保留会签语义。如果会签只是为了让多个角色知情，可以改为通知加单人审批；如果会签涉及责任分担或合规要求，则需要拆成多个审批节点，或借助自动化在节点之间传递状态。无论选哪种方式，都要在映射表中记录降级方案、影响范围和待确认项，并在试迁移阶段让业务代表实际走一遍，确认降级后的审批结果能被业务接受。降级不等于失败，关键是把差异写清楚并取得业务确认。
脚本类扩展在目标平台没有直接对应能力，迁移时优先改写还是保留外部服务？
取决于脚本的复杂度和调用频率。逻辑简单、调用频繁的脚本，优先用目标平台的自动化配置或开放接口改写，减少外部依赖；逻辑复杂、调用频率低、且与外部系统紧密耦合的脚本，可以保留外部服务承接，只重新对接触发和回调。两条路径都要在扩展能力对照表中写明验证方法，例如对比改写前后的输入输出结果，或触发一次真实事件确认外部服务正常响应。改写前先梳理脚本实际承担的功能，避免把已经废弃的逻辑一起迁过去。
试迁移只跑一条流程，怎么判断映射结果可以推广到其他流程？
试迁移验证的是映射方法和配置链路，不是所有流程的具体规则。一条流程跑通后，重点看三类结论是否成立：状态与状态类别的对应关系是否被业务认可、流转条件的表达方式是否可行、自动化触发与通知是否按预期执行。这三类结论成立，说明映射方法可以复用，其他流程按同一张映射表逐条填写即可。如果试迁移流程本身比较特殊，例如涉及外部集成，建议再补一条普通流程做对照，避免把特殊场景的结论直接套用到全部流程。
分批切换期间旧平台还要保留多久，回退演练需要做到什么程度？
旧平台的保留期限以完成一轮完整业务周期为准，覆盖月结、版本发布或审批高峰等关键节点，确认新平台在这些节点上行为稳定后再收缩旧平台权限。回退演练至少验证两件事：配置能恢复到切换前状态，旧平台上的历史记录仍可查询。演练时选一个已切换的流程类型，模拟触发停止条件，执行回滚并检查状态、权限和通知是否恢复正常。演练结果记入回退预案，作为后续批次进入条件的依据。
