工作流与扩展能力迁移的关键，是把来源平台的节点、状态、字段规则、权限和插件接口逐项盘点，建立“来源行为—目标实现”的映射表，再按试迁移、核验、切换与回退推进。本文聚焦工作流行为与扩展能力的迁移方法，记录数据搬运和上线后的日常配置不在讨论范围；兼容版本、接口限制等条件需在切换前查证。
要点总览（TL;DR）
- 迁移对象按工作流、状态、字段、权限、扩展五类登记，记录数据搬运和上线后的日常配置不纳入本次范围。
- 映射以节点和状态为单位，每项标注等价、改写或降级，并写明对流转效率、报表统计和用户操作的影响。
- 插件与接口先做调用方清单，再选择原生能力承接、接口重建或外部服务继续承担，无法等价时保留人工补偿环节。
- 试迁移选取含审批分支、并行流转、字段联动和扩展点的代表性工作流，用配置截图、测试记录和调用日志留下核验证据。
- 切换按基础配置与权限、工作流、扩展接口的顺序推进，预设关键流程阻断、权限越权、接口不可用三类回退触发条件。
迁移范围：工作流、状态、字段、权限与扩展各管什么
迁移开始前先把对象边界划清，可以避免把“配置搬家”和“行为重建”混在一起。工作流迁移的对象是节点、流转条件和状态语义：某个审批节点在什么条件下触发、驳回后回到哪一步、并行分支如何汇合，这些都属于行为层面的内容，需要在目标平台重新表达，而不是简单复制一份配置。状态语义尤其容易被低估，来源平台里一个“待验证”状态可能同时承担测试完成和验收开始的含义，迁移时要判断它在目标平台应保留、拆分还是合并。
字段规则关注的是数据进入系统时的约束：哪些字段必填、字段之间如何联动、状态变化时是否触发校验。权限关注角色与可见范围，包括谁能流转、谁能编辑、谁只能查看。扩展能力则覆盖插件、脚本、Webhook 和开放接口，它们往往承载了来源平台之外的业务逻辑，是迁移中最需要单独处理的部分。
据此可以整理出一张迁移对象清单，按五类登记待迁移项：
| 类别 | 登记内容 | 判断要点 |
|---|---|---|
| 工作流 | 节点、流转条件、审批与分支逻辑 | 目标平台能否表达同等触发条件 |
| 状态 | 状态名称、状态含义、状态间转换 | 语义是否一一对应，是否需要合并或拆分 |
| 字段 | 字段类型、必填规则、联动与校验 | 规则能否在目标平台以配置方式实现 |
| 权限 | 角色、可见范围、操作权限 | 角色模型差异是否导致权限扩大或收窄 |
| 扩展 | 插件、脚本、Webhook、接口调用 | 有无原生替代，或需接口重建、外部承接 |
记录数据的搬运与字段值清洗属于另一项工作，目标平台上线后的流程调整和权限治理也属于日常配置。把这两块排除在本次迁移之外，可以让映射和核验集中在行为是否一致上。
迁移前输入：版本、清单与依赖盘点
迁移的可靠性取决于启动前掌握的信息是否完整。首先要记录来源平台与目标平台的版本，包括来源侧工作流引擎的版本、已安装插件的版本，以及目标平台对应的产品版本。版本信息决定了哪些配置可以原样对应、哪些需要改写，也是后续查证兼容性的基础。来源资料未给出具体兼容矩阵时，应把版本对应关系列为待查证项，在试迁移前完成确认。
其次是工作流与扩展能力的现状清单。清单应覆盖全部在用工作流及其节点、状态、字段规则和权限设置，同时列出每个插件、脚本和 Webhook 的用途。仅凭管理员记忆整理容易遗漏低频但关键的流程，建议从系统配置导出结合业务方访谈交叉核对。
依赖关系是容易被忽略的输入。一个 Webhook 可能被外部报表系统调用，一个脚本可能依赖特定字段的取值格式。需要为每个扩展点记录调用方、触发条件、依赖系统和失败后的影响。迁移窗口、参与角色与责任人同样要提前确定：谁负责工作流映射、谁负责接口验证、谁有权批准切换，都应在输入清单中写明。
把上述内容汇总为迁移输入清单，并把无法确认的兼容性条件单列为待查证问题，例如目标平台对来源平台某版本工作流配置的支持范围、开放接口的调用限制与鉴权方式。这些问题在正式切换前必须有明确结论，不能默认等价。
行为映射方法：从来源规则到目标实现
映射的基本单位是节点和状态，而不是整条工作流。逐节点、逐状态建立映射表，每一行记录来源项、目标实现方式、处理类型和影响说明。处理类型分为三类：等价，即目标平台可以用配置直接表达相同行为；改写，即行为可以通过不同配置组合实现，但结构或触发方式发生变化；降级，即目标平台无法完整表达，需要以简化流程或人工环节替代。三类处理都要在表中写明对流转效率、报表统计和用户操作的影响。
状态语义差异是映射中最需要判断的部分。来源平台的中间状态如果在目标平台没有对应项，可以选择合并到相邻状态、拆分为两个状态，或新增一个过渡状态。合并会减少流转步骤但可能丢失细粒度统计，拆分增加操作次数但保留过程可见性，新增过渡状态则要同步调整流转条件和权限。无论哪种处理，都应在映射表中标注对历史数据归类和报表口径的影响。
字段规则与权限按同一口径对应。字段的必填与联动校验要确认目标平台能否以配置实现，不能实现的部分转为提交前检查或自动化规则。权限映射要对照角色模型，重点检查迁移后是否出现可见范围扩大，尤其是跨项目查询和敏感字段的访问。
扩展能力的映射先做调用方清单，再选择替代路径。来源资料显示，对于原来依赖 Jira 或 Confluence 插件的功能，ONES 建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配；定制场景在迁移前仍需逐项评估，不能假设所有插件都能一一对应。ONES 提供 API 与 Webhook 等开放能力，可用于承接常用插件场景，具体接口范围与调用限制需查证官方文档。据此，扩展项的处理路径通常有三条：目标平台原生能力承接、通过接口重建、由外部服务继续承担并在流程中保留交接点。无法等价时采用降级方案，并在映射表中说明受影响的业务环节和补偿措施。
| 来源项 | 目标实现方式 | 处理类型 | 影响说明 |
|---|---|---|---|
| 审批节点及触发条件 | 目标平台审批节点与条件配置 | 等价或改写 | 触发条件表达方式不同时需复测 |
| 中间状态 | 合并、拆分或新增过渡状态 | 改写 | 影响流转步骤与统计口径 |
| 字段联动校验 | 配置校验或自动化规则 | 等价或改写 | 校验时机可能从保存时变为流转时 |
| 插件功能 | 原生能力、接口重建或外部承接 | 改写或降级 | 需逐项评估，保留人工补偿环节 |
| Webhook 调用 | 目标平台开放接口 | 改写 | 调用方需同步调整地址与鉴权 |
映射表完成后，它同时是试迁移的测试用例来源和切换时的核对依据。在目标平台侧，工作流配置与权限管理是承载这些映射结果的落点，ONES 的迁移方案覆盖项目、工作项、状态、字段、流程等对象，并支持问题类型、工作流、字段配置、权限配置等系统配置的迁移，具体对应关系仍需按上表逐项评估。
试迁移与核验：用证据确认行为一致
试迁移的目的是用少量代表性对象验证映射表是否成立，而不是提前搬运全部数据。选取时应覆盖不同类型的工作流：包含审批分支的、包含并行流转的、依赖字段联动的，以及至少一个使用插件或 Webhook 的扩展点。每个被选中的工作流准备一组测试记录，覆盖正常流转、驳回、条件不满足和权限受限四种情形。
核验按映射表逐项进行，检查四类结果：流转结果是否符合预期路径，状态变化是否与设计一致，字段校验是否在正确时机触发，权限效果是否与来源平台相当。接口与插件的验证要单独进行，确认调用能成功返回、数据格式符合调用方预期、失败时有可观察的错误信息。权限核验建议用不同角色的测试账号实际操作，而不是只查看配置页面。
每项核验都要留下可复核的证据：配置截图、测试记录、流转前后的状态对比、接口调用日志。证据与映射表中的行对应，便于差异出现时快速定位。发现差异后，先判断是映射设计问题还是配置执行问题，修正后重新执行同一组测试，并在核验记录中保留修正前后的对比。试迁移核验记录与差异修正清单应作为切换评审的输入，未关闭的差异需要明确处理方式。
切换、回退与停止条件
正式切换按依赖顺序推进：先切换基础配置与权限，再切换工作流，最后切换扩展接口。扩展接口放在最后，是因为它依赖工作流和字段已经稳定。切换期间安排一段并行运行，来源平台保持只读或有限写入，目标平台承接新流转，便于对比两边结果。并行期的长度取决于业务节奏，至少覆盖一个完整的工作流周期。
回退触发条件应提前写明，常见的有三类：关键工作流在目标平台无法完成流转，导致业务停滞；权限配置出现越权，用户能看到或修改不应访问的内容；接口不可用且无临时替代，影响外部系统对接。触发后由预先指定的责任人判断是局部修正还是整体回退。回退的前置准备包括来源平台在切换窗口内保持可写、保留切换前的完整配置备份、以及明确回退后的数据补录方式。
停止条件与升级路径同样需要明确：试迁移中关键差异未关闭、待查证的兼容性问题没有结论、接口鉴权方式未确认，都应暂停切换并升级到迁移负责人决策。切换完成后设置观察期，逐日检查工作流完成率、异常流转记录和接口调用失败情况，确认稳定后再关闭来源平台的写入权限。ONES 建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配，这一思路与上述切换顺序一致。
| 检查项 | 触发条件 | 责任人 | 确认方式 |
|---|---|---|---|
| 暂停切换 | 关键差异未关闭或兼容性未查证 | 迁移负责人 | 评审会签字确认 |
| 局部修正 | 单个工作流或接口异常 | 对应模块负责人 | 修正后复测通过 |
| 整体回退 | 关键流程阻断、权限越权、接口不可用 | 迁移负责人与业务负责人 | 回退检查表逐项确认 |
| 关闭来源写入 | 观察期无异常 | 系统管理员 | 观察记录归档 |
常见问题
来源平台的工作流版本较旧，目标平台能否直接承接原有配置？
不能默认承接。迁移前应记录来源侧工作流引擎版本、已安装插件版本和目标平台产品版本，把版本对应关系列为待查证项，在试迁移前完成确认。版本差异通常影响条件表达方式和字段校验时机，需要在映射表中标注为改写项，并用代表性工作流复测。来源资料未给出具体兼容矩阵时，以试迁移的实际结果作为判断依据。
插件功能在目标平台没有对应项，迁移时怎么处理？
先梳理实际使用的插件清单，记录每个插件的用途、调用方和依赖系统，再判断处理路径：目标平台原生能力承接、通过开放接口重建，或由外部服务继续承担并在流程中保留交接点。ONES 建议对原来依赖 Jira 或 Confluence 插件的功能，通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配，定制场景仍需逐项评估。无法等价时采用降级方案，在映射表中写明受影响的业务环节和人工补偿措施。
权限迁移后如何确认没有出现越权？
用不同角色的测试账号实际操作，而不是只查看配置页面。核验内容包括：跨项目查询是否能看到不应访问的工作项、敏感字段是否对受限角色可见、流转和编辑操作是否符合角色设定。发现差异时先判断是角色模型对应问题还是配置执行问题，修正后重新执行同一组测试，并在核验记录中保留修正前后的对比。权限配置属于可迁移的系统配置项，具体对应关系需在迁移前逐项核对。
并行运行期间，来源平台和目标平台的数据如何处理？
并行期来源平台保持只读或有限写入，目标平台承接新流转，便于对比两边结果。并行期长度取决于业务节奏，至少覆盖一个完整的工作流周期。切换前保留来源平台的完整配置备份，并明确回退后的数据补录方式，避免并行期内产生的记录在回退时丢失。观察期逐日检查工作流完成率、异常流转记录和接口调用失败情况，确认稳定后再关闭来源平台的写入权限。
试迁移发现差异，应该先修正映射还是先改配置？
先判断差异来源：如果目标平台无法表达来源行为，属于映射设计问题，需要调整处理类型或降级方案；如果目标平台可以表达但配置有误，属于执行问题，直接修正配置。两类问题修正后都要重新执行同一组测试，并在核验记录中保留修正前后的对比。未关闭的差异需要明确处理方式，作为切换评审的输入，关键差异未关闭时应暂停切换。
