迁移配置业务确认是在正式切换前，把来源平台的工作流、状态语义、字段规则、权限、插件与接口逐项与目标平台配置做业务侧核对：先锁定范围与版本，再建立配置项清单和映射表，由业务负责人逐条确认等价、替代或放弃，并留下可复核的签字证据。确认通过才进入试迁移与切换，未确认项进入待办或触发回退。本文给出范围表、映射表、证据清单和回退判定表四份交付物，适用于研发工具迁移准备阶段，不涉及历史记录数据的搬运。
要点总览（TL;DR）
- 迁移配置业务确认的对象是工作流、状态语义、字段规则、权限、插件与接口六类配置，历史记录数据搬运和目标平台上线后的日常配置治理不纳入本次确认。
- 确认前需备齐来源配置快照、目标平台可配置项说明、字段字典、权限矩阵、接口清单与插件使用记录，缺失材料标注待验证，不默认等价。
- 逐项确认以映射表为载体，每条配置项记录来源配置、目标配置、语义差异、处理方式（等价/替代/放弃/待验证）、确认人与确认日期。
- 确认结论需实名签字或系统留痕，关键配置全量复核，并与试迁移实际行为比对，差异回写映射表形成闭环。
- 核心工作流或关键权限无法等价且无业务可接受的替代方案时停止进入试迁移；高影响面未签字项阻塞试迁移，低影响面项切换前闭环。
确认什么：来源、目标与配置范围
业务确认的第一步是把对象边界写清楚，否则确认会滑向两个方向：一是把记录数据搬运混进来，二是把目标平台上线后的日常配置治理提前拉进来。这两类工作各有责任人和节奏，放进同一次确认会让结论无法收敛。
范围表需要先固定三个基本信息：来源平台与目标平台的名称、各自版本、配置快照的时点。配置在迁移准备期间仍可能被修改，快照时点决定了本次确认比对的是哪一版配置。建议在范围表中写明快照的导出日期和导出人，后续所有映射结论都以该快照为准；来源侧如有变更，走变更登记而不是直接覆盖原表。
纳入确认的配置类型建议按以下六类划分，每类单独成批：
- 工作流：流程节点、流转条件、审批环节、自动化触发规则。
- 状态语义：状态名称背后的业务含义，例如“已解决”在来源平台是否等同于“待验证”。
- 字段规则：必填、默认值、可选值范围、联动与校验逻辑。
- 权限：项目角色、空间权限、字段级可见性、操作权限。
- 插件：来源平台实际安装并投入使用的扩展功能。
- 接口：对外提供的 API、Webhook 及被外部系统调用的集成点。
明确排除项同样要写进范围表：历史记录数据的搬运与字段级数据映射另行处理；目标平台上线后的日常配置治理属于运营阶段工作。排除项写清楚，是为了让业务方在确认会上不反复讨论数据量和清洗规则。
每条配置项的确认结论统一为三种状态。等价指目标平台的行为与来源一致，业务方无需改变操作习惯；替代指目标平台以不同机制承接同一业务目的，需要业务方接受操作方式的变化；放弃指经业务确认该配置不再需要。三种状态都要写明判断依据，不能只填结论。
| 范围表字段 | 填写要求 | 示例 |
|---|---|---|
| 来源平台 / 版本 | 名称加版本号，注明配置快照日期 | 来源平台 A，版本 X，快照 2026-03-01 |
| 目标平台 / 版本 | 名称加版本号，注明可配置项说明的获取时间 | 目标平台 B，版本 Y |
| 纳入配置类型 | 从六类中勾选，写明批次 | 工作流、状态语义（第一批） |
| 排除项 | 写明排除内容与归属阶段 | 历史记录数据搬运，归数据迁移阶段 |
| 结论状态口径 | 等价、替代、放弃的定义 | 见上文三类定义 |
确认前的输入与依赖
业务确认会开得是否有效，取决于会前材料是否齐备。缺少来源配置的完整导出，确认会只能凭记忆讨论；缺少目标平台可配置项说明，业务方无法判断等价还是替代。建议在确认启动前逐项核对输入清单，缺一项就在清单上标注责任人和补齐时间。
必备输入包括四类材料：来源平台的配置导出或逐屏截图，覆盖工作流、字段、权限、插件安装记录；目标平台的可配置项说明，说明哪些机制可以承接哪类配置；字段字典，解释每个字段的业务含义与取值；权限矩阵，列明角色与权限的对应关系。接口清单和插件使用记录单独整理，插件记录应包含插件名称、使用部门、使用频率和依赖的外部系统。
角色分工建议按三层设置。业务负责人对“这个配置还要不要”做最终判断，对放弃项和替代项签字；流程 Owner 负责工作流与状态语义的具体比对，解释每个流转条件的业务原因；平台管理员负责提供两侧配置材料、执行目标平台的配置操作，并对技术可行性给出意见。三层角色中，业务负责人不能由平台管理员兼任，否则替代方案是否可接受缺少独立判断。
输入缺失时的处理原则是标注待验证，不默认等价。例如目标平台某项字段校验能力尚未取得说明，该配置项在映射表中记为“待验证”，进入待办清单，由平台管理员补充材料后二次确认。待验证项不阻塞其他批次的确认，但在试迁移前必须有结论。
| 输入材料 | 提供人 | 缺失时的处理 |
|---|---|---|
| 来源配置导出或截图 | 平台管理员 | 标注缺失范围，该批次暂缓 |
| 目标平台可配置项说明 | 平台管理员 | 相关配置项记为待验证 |
| 字段字典 | 流程 Owner | 字段语义存疑项单独列出 |
| 权限矩阵 | 平台管理员 + 业务负责人 | 权限项暂缓确认 |
| 接口清单与插件使用记录 | 平台管理员 | 插件批次暂缓，先补使用清单 |
逐项确认方法：配置项清单与映射表
逐项确认的核心是一张映射表，每个配置项一行，业务方按同一口径填写。建议按配置类型分批推进，顺序上先做工作流与状态语义，再做字段规则，然后是权限，最后是插件与接口。这个顺序的理由是：状态语义决定了字段和权限的判断基准，插件与接口往往依赖前面几类的结论，放在最后可以减少返工。
映射表建议包含以下字段：配置项编号、配置类型、来源配置描述、目标配置描述、语义差异说明、处理方式（等价/替代/放弃/待验证）、替代方案说明、确认人、确认日期、证据编号。其中“语义差异说明”是最容易被跳过也最关键的一栏，它要求确认人用业务语言写出两侧行为的差别，而不是只写“一致”或“不一致”。
| 字段 | 填写内容 |
|---|---|
| 配置项编号 | 按类型加序号，如 WF-001、FIELD-003 |
| 配置类型 | 工作流 / 状态语义 / 字段规则 / 权限 / 插件 / 接口 |
| 来源配置描述 | 节点、条件、取值或权限范围 |
| 目标配置描述 | 目标平台对应机制及配置方式 |
| 语义差异说明 | 业务行为上的差别，含操作步骤变化 |
| 处理方式 | 等价 / 替代 / 放弃 / 待验证 |
| 替代方案说明 | 替代时写明新机制与业务方需做的调整 |
| 确认人 / 确认日期 | 业务负责人或流程 Owner 实名 |
| 证据编号 | 对应签字记录或系统留痕编号 |
状态语义的判断方法是回到业务动作：这个状态出现后，谁会做什么。如果来源平台的“已解决”触发测试验证，而目标平台的同名状态直接进入关闭，两者语义不同，应记为替代并写明新的验证触发方式。字段规则的判断看三点：必填要求是否一致、可选值范围是否覆盖、联动校验是否保留。取值范围有增减时，要确认增减的取值是否仍被业务使用。
权限确认的要点是角色到权限的映射，而不是用户名单的搬运。逐项核对项目角色、空间权限、字段级可见性和操作权限四层，重点看敏感字段的可见范围是否收窄或扩大。插件与接口的确认先梳理实际使用清单，再逐项做功能匹配；定制场景单独评估，不能假设所有插件都能一一对应。接口项要记录调用方系统、调用频率和失败处理方式，确认目标平台的接口能力能否承接。
争议项的处理规则建议在确认启动时约定：同一配置项业务方与平台管理员意见不一致时，由业务负责人裁决并记录分歧理由；涉及外部系统依赖且短期无法验证的，标记暂缓并设定复核期限，暂缓项不计入确认通过数量。争议项不强行当场结论，但必须有责任人和期限。
确认证据与核验方式
口头确认在迁移切换后无法追溯，业务确认的每个结论都要留下可复核的证据。证据形式可以是映射表上的实名签字、确认会纪要中的逐项表决记录，或在协作平台中由确认人对配置项记录做出的状态确认。无论哪种形式，证据要能回答三个问题：谁确认的、确认的是哪一版配置、依据是什么。
抽样复核建议由未参与原确认的人员执行，抽取比例按配置类型区分：工作流和权限类关键配置全量复核，字段规则类按批次抽取，插件与接口类逐项复核。复核方法是拿映射表结论与两侧实际配置比对，检查“语义差异说明”是否与实际行为一致。交叉验证可以请流程 Owner 与业务负责人分别对同一批关键项给出判断，两人结论不一致的项重新确认。
与试迁移结果比对是核验的关键环节。试迁移跑通后，选取映射表中标记为等价和替代的配置项，检查目标平台中的实际行为是否与映射表描述一致。例如某工作流在试迁移后流转路径与预期不符，说明映射结论有误，应回退该配置项重新确认。试迁移中发现的差异要回写到映射表，形成闭环。
未确认项和风险项单独登记，不与已确认项混在同一张表里。登记内容包括配置项编号、未确认原因、风险描述、责任人和计划完成时间。风险项按影响面分级：影响核心研发流程的为高，影响个别团队操作的为中，仅影响展示效果的为低。高等级风险项在进入试迁移前必须清零或取得业务负责人的书面接受。
回退与停止条件
停止与回退条件应在确认开始前就约定好，而不是等到问题出现再讨论。以下情形建议作为停止条件：核心工作流的流转逻辑在目标平台无法等价实现，且没有业务方可接受的替代方案；关键权限配置无法承接，导致敏感数据可见范围失控；对外接口的调用方系统无法在切换窗口内完成适配。出现上述任一情形，暂停进入试迁移，由业务负责人和平台管理员共同评估。
业务方未签字确认的配置项，处理方式分两种。属于高影响面的，视为未通过，阻塞试迁移；属于低影响面的，登记为待办，允许在试迁移期间并行确认，但切换前必须闭环。不能用“默认沿用来源配置”的方式绕过签字，因为目标平台的配置机制与来源不同，沿用本身就需要确认。
回退的触发点主要有三个：配置盘点阶段发现来源配置导出不完整，回退补充材料；映射阶段发现某类配置的语义差异超出预期，回退重新划分批次和确认口径；试迁移比对发现映射结论与实际行为不符，回退该配置项重新确认。每次回退记录触发原因和处理结果，避免同类问题重复出现。
确认通过后进入试迁移的前置条件建议包括：映射表中无待验证项，或待验证项已全部取得结论；高等级风险项已清零或取得书面接受；业务负责人对确认范围表签字；试迁移的环境、数据范围和回滚方案已就绪。四项条件同时满足，才启动试迁移。
| 判定情形 | 处理动作 | 责任角色 |
|---|---|---|
| 核心工作流无法等价且无替代 | 停止，暂停试迁移 | 业务负责人 + 平台管理员 |
| 关键权限无法承接 | 停止，重新评估权限方案 | 平台管理员 |
| 高影响面配置项未签字 | 阻塞试迁移 | 业务负责人 |
| 低影响面配置项未签字 | 登记待办，切换前闭环 | 流程 Owner |
| 来源配置导出不完整 | 回退配置盘点 | 平台管理员 |
| 试迁移行为与映射不符 | 回退该配置项重新确认 | 流程 Owner |
在确认流程落地时，映射表、签字记录和待办清单需要有统一的承载位置，避免散落在多个文档和聊天记录中。ONES 的工作项状态与权限配置可以承载配置项确认记录：每个配置项作为一条工作项，状态对应等价、替代、放弃、待验证四种结论，确认人和确认日期随记录留存，待验证项进入待办视图跟踪。对于从 Jira 向 ONES 迁移的场景，ONES 的迁移方案覆盖项目、工作项、状态、字段、流程、权限配置等内容，插件类功能建议先梳理实际使用清单，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力做功能匹配，定制场景在迁移前逐项评估。具体映射粒度和接口范围以实际迁移方案与实施评估为准，确认清单中应注明适用版本。
常见问题
业务确认会上业务方与平台管理员对同一配置项判断不一致，怎么处理？
建议在确认启动时就约定裁决规则：同一配置项意见不一致时，由业务负责人裁决，并在映射表中记录分歧理由和裁决依据，而不是当场折中或搁置。涉及外部系统依赖、短期无法验证的配置项，标记为暂缓并设定复核期限和责任人，暂缓项不计入确认通过数量。这样既保证确认进度，也保留后续追溯的依据。
目标平台的某项配置能力暂时拿不到说明材料，能否先按等价处理？
不建议按等价处理。未取得对应能力说明或未完成验证的配置项，应在映射表中记为“待验证”，进入待办清单，由平台管理员补充材料后二次确认。待验证项不阻塞其他批次的确认，但在进入试迁移前必须有明确结论。把未验证项默认等价，会在试迁移比对时暴露差异，反而增加返工。
插件和接口的确认为什么放在工作流、字段、权限之后？
插件与接口往往依赖前面几类的结论。例如某个自动化插件的作用是触发状态流转，只有先确认状态语义和流转规则，才能判断目标平台的流程自动化能否承接同样的业务目的。接口项还需要记录调用方系统、调用频率和失败处理方式，这些信息也建立在字段与权限确认的基础上。先做基础配置、后做扩展能力，可以减少批次间的返工。
确认通过后进入试迁移，需要同时满足哪些条件？
建议四项条件同时满足再启动试迁移：
- 映射表中无待验证项，或待验证项已全部取得结论；
- 高等级风险项已清零，或已取得业务负责人的书面接受；
- 业务负责人已对确认范围表签字；
- 试迁移的环境、数据范围和回滚方案已就绪。
四项缺一，试迁移的比对结果就缺少可靠的基准，发现差异时也难以判断是映射结论有误还是环境问题。
从 Jira 迁移到 ONES 时，插件类功能如何做确认？
ONES 的迁移方案覆盖项目、工作项、状态、字段、流程、权限配置等内容；对于原来依赖 Jira 插件的功能，建议先梳理实际使用的插件清单，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力逐项做功能匹配。企业已有的定制场景在迁移前仍需单独评估，不能假设所有插件都能一一对应。具体映射粒度和接口范围以实际迁移方案与实施评估为准，确认清单中应注明适用版本。
