迁移配置业务确认，是在工具切换前把“哪些配置要迁、迁成什么样、由谁确认、确认到什么程度算通过”逐项落到书面记录的过程。本文给出配置范围清单、五步操作流程、角色分工、一条审批流的完整示例和收尾检查表，帮助迁移负责人把工作流、字段、权限、通知、自动化规则等配置在切换前与业务方确认清楚，并以可留痕的确认单作为放行依据。
要点总览（TL;DR）
- 迁移配置业务确认的对象是工作流、字段与表单、权限角色、通知提醒、自动化规则和集成触发点等行为与能力配置；历史记录数据搬运归数据迁移与映射，上线后的日常配置维护归平台配置治理。
- 确认前先按配置类别列清单，再按影响程度分为必须业务确认、技术确认即可、无需确认三档，把业务方精力集中在影响业务行为的配置上。
- 操作按五步推进：盘点来源配置形成基线、填写目标映射并标注保留/调整/废弃/新增、业务方与技术方分线确认、登记分歧项并指定决策人、汇总形成确认单留痕。
- 业务负责人确认流程行为与审批规则，平台管理员确认权限模型与配置可落地性，迁移执行人维护映射表与差异说明，决策人对分歧项做最终裁定并记录理由。
- 确认阶段收尾以检查表判断：范围内配置项均有结论、分歧项均有决策记录、确认单有签字或系统留痕、映射表与确认单版本一致、未确认项已写明风险与后续处理。
确认前先定范围：哪些配置需要业务确认
确认工作的第一步是划定边界。迁移项目常见的失误是把所有配置一股脑交给业务方逐条看，结果业务方被技术细节淹没，真正影响业务行为的配置反而没被认真确认。合理的做法是先按配置类别列清单，再按影响程度分级，让每一类配置都有明确的确认级别。
按类别列出配置项
研发工具中需要迁移的配置，通常可以归入以下几类：
- 工作流：状态集合、状态流转规则、审批节点、条件分支、流转权限。
- 字段与表单：自定义字段、字段类型、必填与默认值、字段在表单中的布局与显示条件。
- 权限角色：角色定义、角色与人员的对应关系、项目或空间的可见范围、操作权限粒度。
- 通知与提醒：触发事件、通知对象、通知渠道、提醒频率与升级规则。
- 自动化规则：自动流转、自动指派、字段联动、定时任务等规则及其触发条件。
- 集成触发点：与代码仓库、构建流水线、消息工具等外部系统对接时依赖的配置项。
按影响程度分三档
不是所有配置都需要业务方签字。分级的意义在于把业务确认的精力集中在影响业务行为的配置上：
| 确认级别 | 适用配置 | 确认方式 |
|---|---|---|
| 必须业务确认 | 审批节点与审批人规则、条件分支、状态含义、权限可见范围、面向业务人员的通知规则 | 业务负责人逐项确认并留痕 |
| 技术确认即可 | 字段类型映射、自动化规则的实现方式、集成触发点的技术参数 | 迁移执行人与平台管理员确认，结果告知业务方 |
| 无需确认 | 目标平台默认值、与业务行为无关的展示性设置 | 记录处理方式即可 |
明确不在本次确认范围的事项
范围清单还要写清排除项，避免确认会开成无边界的讨论。历史记录数据的搬运与字段映射属于数据迁移与映射工作，由数据迁移专项负责核对；目标平台上线后的日常配置维护与治理属于平台配置治理，由平台管理流程承接。这两类事项在范围清单中标注归属即可，不进入本次业务确认的议程。
范围清单的完成标志是：每一类配置都有条目、有确认级别、有对应责任人，且排除项已写明归属。这份清单同时是后续映射表和确认单的目录基础。
逐项确认的操作步骤：从现状盘点到达成一致
范围确定后，确认工作按五步推进。每一步都有明确的输入、动作和输出，完成标志清晰，便于项目管理者跟踪进度。
第一步：盘点来源配置现状，形成配置基线
输入是范围清单。动作是从来源系统中导出或逐项记录配置现状：工作流画出节点与分支、字段列出名称类型与约束、权限列出角色与人员对应、通知与自动化规则记录触发条件和执行动作。输出是一份配置基线文档，作为后续所有讨论的事实依据。完成标志是范围内每个配置项都有现状描述，且经过迁移执行人自查，不存在“凭印象填写”的条目。
第二步：填写目标映射，标注处理方式
输入是配置基线。动作是逐项填写目标平台上的对应配置，并为每一项标注四种处理方式之一：
- 保留：行为与来源一致，直接对应。
- 调整：目标平台机制不同，需要改变实现方式但保持业务效果。
- 废弃：来源中已无实际使用价值，迁移时不再保留。
- 新增：借迁移机会补充来源中缺失的配置。
输出是配置映射表。完成标志是每个配置项都有处理方式标注，标注“调整”的项写明了差异说明，标注“废弃”和“新增”的项写明了理由。
第三步：业务方确认行为差异，技术方确认可行性
输入是配置映射表。动作分两条线并行：业务方逐项查看“调整”“废弃”“新增”的条目，判断迁移后的流程行为、审批规则、通知效果是否符合实际业务；技术方核对映射在目标平台上的可实现性，包括字段约束是否满足、自动化规则能否等价实现、权限模型是否支持。输出是双方在映射表上的确认意见。完成标志是每个条目都有业务意见和技术意见，无意见的条目视为默认同意并记录确认时间。
第四步：登记分歧项，约定决策人和截止时间
输入是第三步产生的分歧意见。动作是把无法当场达成一致的条目单独登记为待决项，写明分歧内容、双方立场、影响范围，指定决策人和决策截止时间。输出是待决项清单。完成标志是每个待决项都有唯一决策人和明确日期，且决策人已知悉。分歧项不阻塞其他条目的确认，确认工作可以并行推进。
第五步：汇总确认结果，形成确认单并留痕
输入是已确认的映射表和待决项清单。动作是把确认结论汇总成确认单：范围、逐项结论、待决项及裁定结果、确认人和确认日期。输出是签字或系统留痕的确认单。完成标志是确认单与映射表版本对应，业务方与平台方均已完成确认动作。
这五步中产生的映射表、待决项清单和确认单需要在多方之间流转并保留修改痕迹。使用 ONES 工作项承载待决项、用文档承载映射表与确认单，可以让每次确认动作留下版本记录，避免“口头说过”在切换后无从追溯。
角色分工与交付物：谁确认、确认什么
确认流于形式，往往是因为角色边界不清：业务方以为技术方会把关，技术方以为业务方已经看过。下表把每个角色在确认中的职责和交付物固定下来。
| 角色 | 确认内容 | 交付物 |
|---|---|---|
| 业务负责人 | 流程行为、审批规则、通知对象是否符合实际业务；调整项的业务效果是否可接受 | 业务确认意见、确认单签字 |
| 平台管理员 | 权限模型、字段约束、自动化规则在目标平台的可落地性；配置是否符合平台规范 | 技术可行性意见、平台侧确认 |
| 迁移执行人 | 映射表维护、差异说明撰写、确认进度跟踪 | 配置基线、配置映射表、待决项清单 |
| 决策人 | 对分歧项做最终裁定 | 裁定结论及理由记录 |
几个边界需要提前说清。业务负责人确认的是“迁移后业务怎么运转”，不负责判断技术实现方式；平台管理员确认的是“配置能否落地、是否合规”，不替业务方决定流程该不该改；迁移执行人负责把差异讲清楚，让确认人能在理解差异的基础上做判断，而不是替任何一方做决定。决策人通常由迁移项目的负责人或业务线负责人担任，其裁定理由要写入记录，供后续复盘和审计使用。
角色表还应写明替补人。确认阶段跨越数周，关键角色出差或调岗时，没有替补会导致确认链条中断。
示例：一条审批流的迁移配置确认过程
以下示例为演示情景，用于说明确认步骤如何落地。
背景与现状盘点
来源系统中有一条“需求变更审批流”：提交变更申请后，依次经过需求负责人审批、测试负责人评估影响、项目经理终审，金额超过阈值的变更额外增加部门负责人节点；每个节点审批通过后通知申请人，驳回则通知申请人与需求负责人。迁移执行人把节点顺序、条件分支（金额阈值）、通知对象逐项记录进配置基线，并附上来源系统的流程截图作为佐证。
映射与差异标注
映射表中，需求负责人审批、测试负责人评估、项目经理终审三个节点标注为“保留”；金额阈值分支在目标平台通过条件流转实现，标注为“调整”，差异说明写明“触发条件配置位置不同，业务效果一致”；驳回通知在原流程中只通知两人，业务方在确认会上提出应同时通知变更发起人，该条目标注为“新增”。
业务确认与签署
业务负责人逐项查看映射表，对“调整”的条件分支要求演示一次触发效果后再确认，技术方现场演示后业务方签署确认意见。对“新增”的通知对象，业务负责人确认名单无误。确认单记录了三项保留、一项调整、一项新增的结论，业务方与平台管理员分别签字。
遗留分歧的处理
部门负责人节点的触发阈值，业务方希望从固定金额改为按项目等级区分，平台管理员指出目标平台当前配置方式下需要额外设计规则。该条目登记为待决项，决策人为业务线负责人，约定三个工作日内裁定。裁定结果为第一阶段沿用固定金额阈值，项目等级规则列入上线后优化清单，理由和后续安排写入待决项记录。这条审批流的确认至此闭环，未决部分有明确的责任人和时间点，不阻塞整体切换计划。
完成检查：确认工作可以收尾的标志
确认阶段能否放行进入切换，用一份检查表逐项核对，避免凭感觉判断“差不多了”。
| 检查项 | 通过标准 |
|---|---|
| 范围覆盖 | 范围清单内每个配置项都有确认结论，无悬空项 |
| 分歧闭环 | 每个分歧项都有决策记录、决策人和裁定时间 |
| 确认留痕 | 确认单有业务方与平台方签字或系统留痕，确认人身份和日期可查 |
| 版本一致 | 映射表版本号与确认单引用的版本一致，确认后无未记录的修改 |
| 未确认项处理 | 确因客观原因未确认的条目，已写明风险、影响范围和后续处理方式，并经决策人认可 |
五项全部通过，确认阶段即可收尾，映射表和确认单移交切换执行环节作为配置实施的依据。任何一项不通过，都应回到对应步骤补齐，而不是带着未闭环的条目进入切换。确认单、待决项和映射表的版本记录可以在 ONES 文档与工作项中持续留存，切换后如出现配置争议，可据此回溯当时的确认结论和责任分工。
常见问题
业务方在确认会上对某个配置项迟迟无法拍板，确认工作要不要停下来等？
不需要整体停下来。把该条目登记为待决项，写明分歧内容、双方立场和影响范围，指定唯一决策人和决策截止时间，其余条目继续确认。待决项清单单独跟踪，决策人裁定后把结论补入确认单即可。需要注意的是，待决项不能无限期挂着，截止时间到期仍未裁定的，应由迁移项目负责人升级处理，避免带着悬空项进入切换。
来源系统里有些配置长期没人用，迁移时还要不要走业务确认？
建议先由迁移执行人在映射表中标注为“废弃”，写明判断依据，例如近一段时间无使用记录或对应流程已停用，再提交业务负责人确认一次。业务确认的重点是确认“废弃”不会影响仍在运转的业务，而不是逐条讨论历史配置的细节。标注“废弃”的条目同样要进入确认单，保留处理理由，便于切换后回溯。
业务确认和技术确认可以合并成一次会议吗？
可以合并召开，但两条确认线要分开记录。业务方关注的是迁移后流程行为、审批规则和通知效果是否符合实际业务；技术方关注的是字段约束、自动化规则和权限模型在目标平台上能否落地。合并会议容易让技术细节挤占业务讨论时间，建议映射表按条目分别留出业务意见和技术意见两栏，会上同步过、会后各自补签，确保两类意见都有明确的责任人。
确认单签完字之后，切换前又发现配置需要调整，怎么处理？
按变更处理，不直接改映射表。记录变更内容、提出人和原因，评估对已确认结论的影响范围，由原确认人重新确认受影响条目，并更新确认单版本号。检查表中“映射表版本与确认单版本一致”这一项就是为这种情况设置的：确认后发生的修改如果没有重新走确认，版本会对不上，切换时就缺少可追溯的依据。
关键角色在确认期间调岗或长期出差，确认链条怎么保持不断？
在角色职责表中提前写明每个角色的替补人，并让替补人参与确认过程、了解已确认结论。关键角色离岗时由替补人接续确认动作，确认单上记录实际确认人身份和日期。如果替补人也无法覆盖，应由决策人指定临时确认人并说明授权范围，避免出现“没人签字、确认停摆”的情况。
