迁移配置的业务确认，依据应围绕“行为等价”来准备：把源系统的工作流、状态语义、字段规则、权限、插件与接口现状整理成基线，再逐项说明目标侧如何重建或调整，形成一份带差异说明、责任人和验收口径的配置对照表。本文按准备材料、核对步骤、角色分工、示例和完成检查展开，适用于工作流与扩展能力迁移的确认阶段，不涉及记录数据的搬运。
要点总览（TL;DR）
- 迁移配置的业务确认以行为等价为核心，会前备齐源系统配置基线、目标侧等价映射说明、差异与影响清单、确认与验收口径四类材料。
- 工作流与状态语义按状态逐条对照进入条件、退出条件和责任人，名称相同但含义不同的状态单独标注，由业务负责人逐项确认。
- 字段规则、权限、插件与接口分别建表核对，每项结论落在等价、调整后可用、需替代方案、暂不迁移四类之一，待验证项写明责任人和验证时间。
- 业务负责人确认语义与差异接受意见，技术负责人确认可实现性与替代路径，迁移负责人汇总对照表并记录结论，确认记录要能追溯到具体配置项。
- 确认会结束前用检查项逐条判断，不满足的列为遗留事项，避免口头共识替代书面确认。
业务确认要拿出的四类依据
业务确认会能否开得有效，取决于会前是否备齐了可逐项核对的材料。建议把确认依据分成四类，直接作为会议材料目录，每类材料对应一个明确的问题。
| 依据类别 | 回答的问题 | 典型内容 | 准备人 |
|---|---|---|---|
| 源系统配置基线 | 现在是什么样 | 工作流定义、状态清单与含义、字段规则、角色与权限、在用插件与接口清单 | 技术负责人 |
| 目标侧等价映射说明 | 目标平台怎么重建 | 每项配置在目标平台的对应配置方式、调整点、配置截图或说明 | 技术负责人 |
| 差异与影响清单 | 哪些做不到等价，影响多大 | 差异描述、受影响的业务场景、补偿做法、接受人 | 迁移负责人汇总，业务负责人确认 |
| 确认与验收口径 | 谁确认、确认到什么程度算通过 | 确认人、确认方式、验收标准、遗留事项处理规则 | 迁移负责人 |
四类材料中，源系统配置基线最容易准备不足。常见问题是只导出工作流名称和状态列表，缺少状态含义说明和实际流转记录，导致确认会上无法判断某个状态在业务上究竟代表什么。基线应包含配置本身和配置背后的业务解释两部分。
差异与影响清单需要写明接受人。差异项如果没有明确的业务接受人，后续出现争议时无法追溯是谁认可了这项调整。确认与验收口径则要事先约定：哪些事项必须业务负责人签字，哪些可以由技术负责人判断后记录备案。
工作流与状态语义的确认步骤
工作流迁移的高风险点集中在状态语义。两个系统里都叫“已解决”的状态，进入条件、退出条件和责任人可能完全不同。核对时应以状态为单位逐条对照，而不是以工作流整体做笼统比较。
输入准备。收集源系统的工作流定义、状态流转记录和状态含义说明。流转记录可以从历史工作项中抽样，观察实际使用中是否存在绕过标准流程的情况；状态含义说明通常需要业务负责人补充，配置里往往只有状态名称。
逐条对照。按状态建立映射表，对每个状态标注四项内容：进入条件、退出条件、责任角色、可执行的操作。名称相同但含义不同的状态单独标红，作为重点确认项。名称不同但含义接近的状态，说明合并或改名的理由。
输出状态映射表。映射表至少包含源状态、目标状态、语义是否等价、差异说明、处理方式五列。处理方式限定为等价、调整后可用、需替代方案、暂不迁移四类结论，避免出现“待定”长期挂起。
| 源状态 | 目标状态 | 语义是否等价 | 差异说明 | 处理方式 |
|---|---|---|---|---|
| 待业务确认 | 待评审 | 否 | 源系统由业务方确认，目标系统评审人包含技术角色 | 调整后可用 |
| 已关闭 | 已完成 | 是 | 进入条件一致，均要求验收通过 | 等价 |
完成标志。业务负责人对每个状态的进入条件、退出条件和责任人没有异议，并在状态映射表上确认。存在异议的状态回到技术负责人处调整方案，调整后重新确认。口头认可不算完成，确认结论要落到映射表对应行。
字段规则、权限与扩展能力的确认要点
状态之外，字段规则、权限和插件接口是三类性质不同的配置，应分别建表核对，避免混在一张表里导致结论含糊。
字段规则核对
逐项对照必填设置、默认值、校验逻辑和联动规则。必填和默认值对照相对直接；校验逻辑和联动规则需要看实际效果，例如某字段在特定状态下才必填、某选项变化后触发另一字段的显示或清空。这类规则在目标平台可能需要用不同的配置方式实现，核对时要记录实现路径，而不只是记录“已配置”。
权限等价性核对
按角色、可见范围、操作权限三个维度对照。重点检查两类情况：源系统中通过项目角色间接获得的权限，在目标平台是否有对应机制；源系统中依赖插件实现的细粒度权限，目标平台是否需要调整角色设计来近似实现。权限差异往往影响面广，差异项应单独列出并注明受影响的用户群体。
插件与接口能力核对
先梳理源系统实际在用的插件和接口清单，标注每个插件的使用场景和依赖程度，再逐项评估目标侧是否存在替代路径。评估结论分为有直接替代、需组合配置实现、需定制开发、暂无替代四类。暂无替代或需定制开发的项，标注为待验证，写明责任人和验证时间，不在此阶段直接判定为不可迁移。
以ONES的迁移方案为例，其Jira迁移涉及项目、工作项、状态、字段、流程、权限配置等内容，插件方面提出先梳理实际使用的插件，再通过项目、Wiki、测试管理、流程自动化和开放能力做功能匹配，并明确定制场景需要逐项评估。这一处理方式与上述“先清单、再逐项评估”的核对逻辑一致，具体到某个插件能否替代，仍需在项目中验证。
完成标志。字段规则、权限、插件与接口三张核对表中，每一项都有明确结论，结论落在等价、调整后可用、需替代方案、暂不迁移四类之一；待验证项有责任人和验证时间。
角色分工与确认交付物
业务确认流于形式，通常是因为角色职责不清：技术团队整理完材料，业务方只看结论不看依据。明确三类角色的分工，可以让确认过程有据可查。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 业务负责人 | 确认状态语义与业务规则，对差异项给出接受或拒绝意见 | 状态映射表确认意见、差异接受记录 |
| 技术负责人 | 确认配置可实现性，给出接口与插件的替代路径评估 | 目标侧等价映射说明、待验证事项清单 |
| 迁移负责人 | 汇总配置对照表，组织确认会，记录结论和遗留事项 | 配置对照表、差异清单、确认记录 |
三类角色之外，建议设置一名记录人，专门负责把确认会上的结论逐条落到配置对照表的对应行。确认记录应包含日期、参与人、逐项结论和遗留事项，遗留事项写明责任人和下次确认时间。
这些材料在迁移期间会反复更新，适合放在统一的工作项和文档空间中管理。以ONES为例，配置对照表可以作为文档沉淀，差异项和待验证事项可以建为工作项并指派责任人，状态变更和确认记录随工作项留痕，便于迁移负责人随时汇总进度。这一衔接针对的是确认材料的管理动作，具体配置的等价性判断仍由业务和技术负责人完成。
一个配置确认的示例
以下为演示情景，用于说明从源配置到确认结论的完整过程。
场景。某审批流程在源系统中有一个状态“待业务确认”，含义是业务方对申请内容做实质性审核，审核人只能是业务部门负责人。目标平台的对应状态叫“待评审”，默认评审人包含技术角色，且评审通过后直接进入“已完成”。
核对过程。列出源配置：进入条件为提交后自动进入，退出条件为业务负责人同意或驳回，责任人为业务部门负责人。目标配置：进入条件相同，退出条件为任一评审人通过，责任人包含业务和技术角色。差异点有两处：评审人范围扩大，退出后的下一状态不同。影响是技术角色可能代替业务方做出实质审核结论，且缺少业务验收环节。
确认结论。处理方式定为调整后可用：在目标平台调整评审人配置，限定为业务部门负责人；在“待评审”与“已完成”之间增加业务验收状态。责任人为技术负责人，验收方式为用三条历史审批单走通全流程并核对状态流转记录。业务负责人确认该方案并记录接受意见。
可迁移规律。同类配置的核对思路可以复用：先比对进入条件、退出条件和责任人三项，再检查状态流转的上下游衔接，最后用真实历史记录验证。名称相同不是等价依据，流转路径一致才是。
确认完成前的检查项
确认会结束前，用以下检查项逐条判断，任何一项不满足都应列为遗留事项而不是默认通过。
- 工作流、状态、字段规则、权限、插件与接口五类配置是否都有对照记录，且每项有明确结论。
- 名称相同但语义不同的状态是否已单独标注，并由业务负责人确认处理方式。
- 每个差异项是否写明了业务影响、补偿做法和接受人。
- 待验证事项是否都有责任人和验证时间，且验证时间早于计划切换时间。
- 确认记录是否能追溯到具体配置项，而不是只有会议纪要层面的概括结论。
- 确认与验收口径是否事先约定，包括哪些事项需要业务负责人签字、哪些由技术负责人判断备案。
- 暂不迁移的配置项是否说明了业务上的过渡安排。
以上检查项全部满足，可以认为工作流与扩展能力的迁移配置业务确认达到可交付状态。后续如出现新的差异项，按同一流程补充核对并更新配置对照表，保持确认记录与配置现状一致。
常见问题
源系统的工作流文档不完整，状态含义只有配置名称，确认会还能开吗？
可以先开，但需要把补全状态含义作为会前动作。配置里通常只有状态名称，进入条件、退出条件和责任角色往往存在于业务人员的经验中。建议从历史工作项中抽样流转记录，观察实际使用情况，再请业务负责人逐条补充含义说明。补全之前，相关状态在映射表中标注为语义待确认，不作为已确认结论。
某个插件在目标平台找不到直接替代，是否要等验证完再继续其他配置的确认？
不必整体暂停。插件与接口的评估结论分为有直接替代、需组合配置实现、需定制开发、暂无替代四类，暂无替代或需定制开发的项标注为待验证，写明责任人和验证时间，其余配置照常推进确认。待验证项的验证时间应早于计划切换时间，避免在切换前才暴露无法替代的问题。
业务负责人和技术负责人对某个状态的处理方式意见不一致，怎么处理？
把分歧落到具体配置项上讨论：业务负责人判断该状态的业务含义和影响，技术负责人说明目标平台的实现路径和限制。如果暂时无法达成一致，在状态映射表中记录双方意见、分歧点和下次确认时间，由迁移负责人跟踪。涉及业务规则取舍的结论由业务负责人拍板，涉及实现可行性的结论由技术负责人确认，避免用笼统的会议纪要掩盖分歧。
确认记录只写会议纪要够不够？
不够。会议纪要通常只记录概括结论，无法对应到具体配置项。确认记录应逐条落到配置对照表的对应行，包含日期、参与人、每项结论和遗留事项。差异项要写明业务影响、补偿做法和接受人，后续出现争议时可以追溯到是谁在什么依据下认可的调整。
迁移切换后才发现某项配置语义不一致，还能补确认吗？
可以按同一流程补充核对：更新配置对照表，标注差异点、业务影响和调整方案，由业务负责人确认接受意见，技术负责人给出实现路径，迁移负责人记录结论并更新待验证事项。补充确认后保持确认记录与配置现状一致，避免对照表停留在切换前的版本。
