工作流与扩展能力迁移的对象是流程规则、状态流转、触发条件、自动化动作和集成扩展点，历史记录与附件搬运属于另一类任务。迁移时先把源平台配置盘点成可核对清单，再逐项映射到目标平台的等价机制，通过试迁移确认行为一致后分批切换，并为无法等价的部分准备改造项或人工补偿。
要点总览（TL;DR）
- 迁移对象是工作流定义、状态与流转规则、触发与自动化动作、通知规则、字段校验、权限可见性、集成与扩展点；历史记录与附件搬运属于另一类任务。
- 映射表按源对象、源含义、目标对象、目标含义、映射类型、差异说明六列组织，映射类型分为直接对应、转换后对应、拆分或合并、需改造、无法对应。
- 同名字段先比对取值集合，再比对触发时机与必填条件，最后比对权限可见范围，三步任一不一致就不能按直接对应处理。
- 试迁移选取高频主流程、复杂分支流程和涉及通知自动化的流程，留存流转路径、通知到达、自动化日志和权限抽查记录作为核验证据。
- 切换按团队、流程或业务线分批并设置并行期，出现关键流程无法流转、通知缺失、权限越界或集成中断时暂停该批并评估回退。
迁移范围：哪些工作流与扩展能力需要搬
迁移开始前先确认方向：从哪个源平台、哪个版本迁到哪个目标平台，源平台由谁维护、目标平台由谁管理。方向一旦确定，后续映射表、试迁移样本和回退方案都围绕这条链路展开，不能中途调换。版本信息要记录到迁移输入清单里，因为不同版本的工作流配置结构、字段类型和扩展接口可能不同，映射时需要以实际版本为准。
纳入本文迁移范围的对象是行为与配置，具体包括以下几类：
- 工作流定义：流程节点、阶段划分、状态集合及其顺序关系。
- 状态与流转规则：谁可以执行哪个流转、流转前需要满足哪些条件、哪些字段在流转时必填。
- 触发与自动化动作：定时触发、字段变更触发、状态变更后自动执行的动作。
- 通知规则：通知对象、通知时机、通知渠道和通知内容模板。
- 字段校验：字段取值范围、格式校验、联动显示与隐藏规则。
- 权限与可见性：角色对工作项、字段、附件的查看与编辑权限。
- 集成与扩展点：与外部系统的接口调用、Webhook、插件或脚本扩展。
历史记录、附件、代码仓库等数据搬运不在本文展开，它们有独立的迁移方案和校验口径。目标平台上线后的日常配置治理同样不属于本次迁移任务，迁移只负责把现有行为搬过去并验证可用。把这两类内容排除在外，可以避免迁移清单无限膨胀，也便于把核验精力集中在行为一致性上。
范围清单确定后按优先级排序。排序依据是使用频率和业务影响：高频使用且中断后直接影响交付的流程排在最前，低频或仅个别团队使用的配置排在后面。优先级会决定试迁移样本的选择和分批切换的顺序，因此需要在清单上明确标注，并由流程负责人确认。
本阶段输入与依赖：迁移前要拿到什么
执行映射前需要准备四类输入材料。第一类是源平台工作流与扩展配置的导出文件或完整截图，包括流程定义、状态列表、流转条件、自动化规则、通知设置和集成配置。第二类是目标平台可用的流程、自动化和集成能力说明，用于判断哪些配置可以对应、哪些需要改造。第三类是基础对照表，覆盖字段、状态、角色和通知对象的名称与含义。第四类是干系人确认记录，明确流程负责人、平台管理员和集成维护方各自确认的范围。
输入材料可以用一张依赖确认表管理，逐项标注是否已获取、由谁提供、确认状态和缺口说明。缺失项不要凭经验推断目标平台不支持，正确做法是先记为待确认项，在试迁移阶段用实际配置验证。例如目标平台是否支持并行分支、自动化动作失败后是否重试，资料没有写明时，先在映射表中标注“待验证”，再通过试迁移观察结果。
| 输入类别 | 具体内容 | 缺失时的处理 |
|---|---|---|
| 源平台配置 | 流程定义、状态、流转条件、自动化规则、通知设置、集成配置 | 补导出或截图；无法获取的部分标记为待确认，在试迁移中重建验证 |
| 目标平台能力 | 流程配置、自动化、通知、权限、开放接口的能力说明 | 向平台管理员或原厂确认，不推断为不支持 |
| 基础对照表 | 字段、状态、角色、通知对象的名称与含义 | 由流程负责人补充语义说明，避免仅凭名称映射 |
| 干系人确认 | 流程负责人、平台管理员、集成维护方的确认记录 | 明确待确认事项的责任人和确认时间，不跳过确认直接切换 |
依赖缺口集中在集成与扩展点时，需要额外确认外部系统的接口是否继续可用、调用凭证是否需要更换。集成维护方应参与映射评审，因为接口字段和调用时机的差异往往在试迁移时才暴露，提前介入可以减少返工。
字段与规则映射：同名字段含义不同怎么处理
映射表建议按六列组织：源对象、源含义、目标对象、目标含义、映射类型、差异说明。映射类型分为五类：直接对应、转换后对应、拆分或合并、需改造、无法对应。每一行都要填写差异说明，即使判定为直接对应，也记录比对依据，便于后续复核和交接。
| 映射类型 | 适用情形 | 处理方式 |
|---|---|---|
| 直接对应 | 名称、取值集合、触发时机和权限范围均一致 | 按原配置迁移，试迁移中抽样确认 |
| 转换后对应 | 含义一致但取值编码或格式不同 | 建立取值转换规则，迁移后核对转换结果 |
| 拆分或合并 | 源平台一个字段或状态在目标平台需要拆成多个，或反之 | 明确拆分规则和合并逻辑，记录对下游通知与自动化的影响 |
| 需改造 | 目标平台有相近机制但规则表达方式不同 | 列为改造项，指定负责人和完成时间 |
| 无法对应 | 目标平台没有等价机制 | 显式记录，评估人工补偿流程或调整业务规则 |
同名字段含义不同是映射中最容易出错的情况。判定分三步：先比对取值集合，确认可选值是否一致；再比对触发时机与必填条件，确认字段在哪些流转节点被要求填写；最后比对权限可见范围，确认哪些角色可以查看和编辑。三步中任一步不一致，就不能按直接对应处理。例如源平台的“优先级”包含五个取值且允许为空，目标平台只有三个取值且默认必填，这种情况应归为转换后对应或需改造，并明确空值如何处理、默认值由谁设定。
状态机映射要关注四个要点：状态数量是否一致、每个流转由哪些角色执行、流转时的必填校验、是否存在并行分支。源平台的状态在目标平台需要合并时，要检查合并后是否影响通知对象和自动化触发条件。并行分支在目标平台没有对应机制时，应记录为改造项，并评估是否可以用串行节点加条件分支近似实现，近似方案同样需要试迁移验证。
自动化动作与通知的映射按触发条件、执行对象、失败处理三项逐一核对。触发条件要确认是字段变更、状态变更还是定时触发；执行对象要确认动作作用于哪些工作项、通知发给哪些角色；失败处理要确认动作执行失败后是否重试、是否通知管理员。三项中任何一项在目标平台表达方式不同，都要在差异说明中写清楚，并纳入试迁移的观察点。
在映射环节，如果目标平台是 ONES，可依据官方资料核对迁移对象：从 Jira 迁移到 ONES Project 时，可迁移项目、系统配置，包括问题类型、工作流、字段配置、权限配置等，具体对应关系仍需逐项核对。对于原来依赖 Jira 或 Confluence 插件的功能，ONES 方案建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配；企业已有的定制场景在迁移前仍需逐项评估，不能假设所有插件都能一一对应。API、Webhook 等开放能力可用于承接部分插件场景，具体接口范围和调用限制需要在映射表中单独确认。
试迁移与核验：怎样证明行为一致
试迁移样本应覆盖三类流程：使用频率最高的主流程、分支和校验条件较多的复杂流程、涉及通知与自动化动作的流程。每类选取一到两个代表，样本数量以能覆盖主要映射类型为准。样本确定后，在目标平台按映射表配置导入或重建，再用样本数据触发流转，逐项比对结果。
试迁移的执行步骤可以按以下顺序推进：
- 按映射表在目标平台完成配置，记录配置过程中的偏差和临时处理。
- 准备样本数据，覆盖正常流转、边界条件和异常分支。
- 触发流转，留存流转路径记录、通知到达记录、自动化执行日志。
- 抽查权限可见性，确认不同角色看到的工作项和字段范围符合预期。
- 将观察结果与源平台行为逐项比对，登记差异。
核验证据要能支撑判断，而不只是“看起来正常”。流转路径记录用于确认状态顺序和流转权限；通知到达记录用于确认通知对象和时机；自动化执行日志用于确认动作是否执行、执行结果和失败处理；权限抽查记录用于确认越权或漏看的情况。证据按流程归档，与映射表行号对应，便于差异回溯。
发现偏差后进入差异登记与回归：记录偏差现象、涉及的映射行、初步原因、修正动作和复测结果。修正后重新触发同一路径，确认偏差消除且未引入新的不一致。核验通过的标准由流程负责人和平台管理员共同确认，确认内容包括样本流程全部通过、差异项均有处理结论、待确认项已闭环或明确转为改造项。签字确认后，该批流程才进入切换计划。
切换节奏与回退条件
分批切换的划分依据有三种：按团队、按流程或按业务线。按团队划分适合各团队流程差异较大的情况，切换后便于就近支持；按流程划分适合核心流程跨团队使用的情况，可以优先切换影响面大的流程；按业务线划分适合业务线之间依赖较少的组织。选择哪种依据取决于流程的共享程度和团队规模，没有统一要求，关键是每批的范围清晰、责任人明确。
每批切换设置切换窗口和并行期。切换窗口内完成配置生效和账号权限调整，并行期内源平台保持只读或有限可用，新发起的流程走目标平台。并行期长度根据流程复杂度和团队适应情况确定，期间安排专人收集问题并每日汇总。并行期结束前完成该批的核验确认，再进入下一批。
回退触发条件需要提前写清楚，常见的有：关键流程无法流转、通知缺失导致责任人未收到待办、权限越界导致不应看到的数据被访问、集成中断导致外部系统无法同步。触发条件应与试迁移的核验项对应，出现任一条件即暂停该批切换，评估是局部修正还是整体回退。回退操作包括恢复源平台的写入权限、暂停目标平台该批流程的新建入口、将并行期内产生的数据按约定处理。回退后的状态恢复方案要提前演练，确认源平台可以正常承接。
停止条件与升级路径同样需要约定：连续出现同类偏差且修正后复现、集成方无法在约定时间内恢复、关键干系人无法确认核验结果，都属于停止推进的信号。停止后由迁移负责人升级到平台管理方和业务负责人，重新评估范围或调整方案，不带着未解决的差异继续切换。ONES 方案把迁移工具、原厂服务和分阶段切换结合起来，作为降低数据丢失或业务中断风险的方式，并在正式迁移前确认数据范围、功能匹配和系统适配；具体批次和回退条件仍需结合企业实际确定。
迁移后的交接与持续维护
切换完成后，配置所有权从迁移项目组移交到目标平台的日常管理角色。交接内容包括工作流定义、自动化规则、通知设置、权限配置和集成凭证的管理权限，以及每项配置的变更审批流程。交接清单逐项列明配置名称、当前责任人、变更审批人和生效范围，双方确认后归档。
映射表和试迁移核验记录是后续排查问题的基础资料，应随交接一并归档，并注明版本和适用范围。后续新增流程或修改现有流程时，按统一规范执行：先在设计稿中说明状态、流转条件、通知对象和自动化动作，经流程负责人审批后在目标平台配置，配置完成后用样本数据验证再上线。规范的具体形式可以是一张配置申请单，也可以是平台内的变更记录，关键是留下可追溯的审批和验证痕迹。
定期复核的触发点包括：业务流程发生调整、集成接口变更、平台版本升级、出现批量流转异常。复核时对照映射表和核验记录，检查现有配置是否仍符合业务规则，发现漂移及时修正。复核频率根据流程变更频率确定，变更频繁的流程缩短复核间隔，稳定的流程可以按季度或半年检查一次。
常见问题
源平台配置拿不到完整导出，只靠截图能完成映射吗？
可以推进，但需要调整做法。截图能覆盖流程节点、状态列表和部分规则，适合先建立映射表初稿；对于截图无法体现的触发条件、失败处理和权限细节，在映射表中标注“待确认”，在试迁移阶段按重建配置的方式验证实际行为。依赖确认表要记录每项缺失内容的责任人和确认时间，避免缺口长期悬置。
目标平台没有与源平台完全等价的状态或分支机制，应该改造流程还是调整业务规则？
先判断差异的影响范围。如果只是状态数量不同，可以通过合并状态并同步调整通知对象和自动化触发条件来解决；如果涉及并行分支这类结构性差异，需要评估用串行节点加条件分支近似实现，近似方案同样要经过试迁移验证。改造流程和调整业务规则两种方式可以并存，关键是每一项都在映射表中写明处理结论、负责人和完成时间，不能默认零损。
试迁移核验通过后，正式切换时还需要重复验证吗？
需要，但范围可以收窄。试迁移验证的是配置行为本身，正式切换还涉及账号权限调整、集成凭证更换和并行期数据走向，这些在试迁移环境中往往不具备完整条件。建议每批切换后在并行期内对关键流程做一次快速回归，重点检查流转是否正常、通知是否到达、权限是否符合预期，确认无异常后再结束该批并行期。
并行期内两个平台同时产生数据，回退时怎么处理？
并行期的数据归属要在切换计划中提前约定。常见做法是并行期内新发起的流程只走目标平台，源平台保持只读，这样回退时不需要合并两边的新数据。如果确实存在双写，回退前要明确哪些记录需要回填、由谁执行、按什么口径核对。回退方案应包含状态恢复步骤，并提前演练一次，确认源平台可以正常承接后续流转。
迁移完成后，新增流程还需要走迁移时的映射表吗？
不需要沿用迁移映射表，但需要建立新的配置规范。新增或修改流程时，先在设计稿中说明状态、流转条件、通知对象和自动化动作，经流程负责人审批后在目标平台配置，再用样本数据验证后上线。映射表和核验记录转为归档资料，在业务流程调整、集成接口变更、平台版本升级或出现批量流转异常时作为复核参照。
