迁移验收标准要能逐项判断通过与否，核心做法是先确定验收对象和检查时点，再把迁移拆成准备、试迁移、正式迁移、切换四个阶段，为每个检查项写明通过标准、证据和负责人，并单独标出阻断项。本文给出一份可直接套用的分阶段检查清单，覆盖从准备到切换放行的验收动作；检查项和问题记录可以在ONES中作为工作项流转，验收结论以文档形式留存。
要点总览（TL;DR）
- 验收标准按准备、试迁移、正式迁移、切换四个阶段设置检查项，每个阶段对应明确的检查时点和放行人。
- 通过标准写成可判断的阈值或状态，例如记录数一致、关键字段抽样一致率达到约定值、关键流程可完整走通。
- 每项检查同时明确证据类型和负责人，比对报告、截图、导出清单、签字记录与问题清单分别对应不同检查项。
- 阻断项单独标出：全量数据缺失或错位、权限越权、关键流程中断、回退方案未验证，不通过不得进入下一阶段。
- 整体完成条件为所有阻断项关闭、非阻断项有明确处理计划，并由切换决策人签字放行。
谁在什么时点使用这份验收清单
这份清单解决的是“谁在哪个节点勾选、谁签字放行”的问题。它面向一次系统或研发工具迁移的验收环节，验收对象包括迁移后的数据、配置、权限、集成关系和关键业务流程。数据映射怎么设计、切换后怎么推广，不在本文范围内，前者属于迁移方案设计，后者属于切换后的运营治理。
检查时点分四个：准备完成时、试迁移结束后、正式迁移结束后、切换放行前。四个时点对应四类角色，职责不能混在一起，否则容易出现“自己迁移、自己验收”的情况。
| 角色 | 主要职责 | 参与时点 | 输出 |
|---|---|---|---|
| 迁移负责人 | 组织迁移执行，提交各阶段检查结果 | 准备、试迁移、正式迁移 | 检查记录、问题清单 |
| 业务验收人 | 按业务口径确认数据与流程可用 | 试迁移后、正式迁移后 | 业务验收意见 |
| 系统管理员 | 核对权限、配置、集成连通性 | 正式迁移后、切换前 | 权限与配置核对记录 |
| 切换决策人 | 确认阻断项关闭，签字放行切换 | 切换放行前 | 放行签字记录 |
使用前需要明确两点边界：清单只验证迁移结果和切换风险，不评价新系统的功能设计是否合理；清单也不替代迁移方案本身，方案里写清映射规则和迁移顺序，清单只检查这些规则执行后的结果。
分阶段检查项：从准备到切换逐项核对
下表是清单主体，每个阶段列出检查项、通过标准、证据、负责人和检查时点。实际使用时可以按项目规模增删检查项，但阻断项建议保留。
| 阶段 | 检查项 | 通过标准 | 证据 | 负责人 | 时点 |
|---|---|---|---|---|---|
| 准备 | 迁移范围清单 | 项目、空间、工作项、附件等对象类型逐项列明，无遗漏项 | 范围清单文档 | 迁移负责人 | 准备完成 |
| 准备 | 字段与对象清单 | 每个对象的字段、状态、流程已列出并与目标系统字段建立对应 | 字段对照表 | 迁移负责人 | 准备完成 |
| 准备 | 回退方案 | 回退触发条件、回退步骤、责任人已书面确认 | 回退方案文档 | 切换决策人 | 准备完成 |
| 准备 | 环境与账号就绪 | 目标环境可访问，迁移账号与验收账号权限已开通 | 账号清单、登录截图 | 系统管理员 | 准备完成 |
| 试迁移 | 样本数据比对 | 抽样记录数与源系统一致，关键字段比对结果符合约定 | 比对报告 | 迁移负责人 | 试迁移后 |
| 试迁移 | 关键流程走通 | 选定的关键业务流程可从发起到关闭完整走通 | 流程截图、操作记录 | 业务验收人 | 试迁移后 |
| 试迁移 | 异常记录与处理闭环 | 试迁移发现的问题全部登记，且有处理结论或处理计划 | 问题清单 | 迁移负责人 | 试迁移后 |
| 正式迁移 | 全量数据核对 | 各对象类型记录数与源系统一致，差异项已逐条说明 | 全量比对报告 | 迁移负责人 | 正式迁移后 |
| 正式迁移 | 权限与配置核对 | 角色与权限对应关系正确，无越权访问 | 权限核对表 | 系统管理员 | 正式迁移后 |
| 正式迁移 | 集成连通性检查 | 与代码库、单点登录、通知等集成点连通，调用结果正常 | 连通性测试记录 | 系统管理员 | 正式迁移后 |
| 切换 | 旧系统只读或停用确认 | 旧系统已按计划设为只读或停用，写入入口关闭 | 配置截图 | 系统管理员 | 切换前 |
| 切换 | 通知与支持通道就位 | 切换通知已发出，问题反馈渠道与值班人已明确 | 通知记录、值班表 | 迁移负责人 | 切换前 |
| 切换 | 回退触发条件明确 | 触发条件、判断人、执行时限已确认并可执行 | 回退方案签字页 | 切换决策人 | 切换前 |
准备阶段容易漏掉的是字段与对象清单的对应关系。以Jira迁移为例，ONES的方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，验收时就要按这些对象类型逐类核对，而不是只看项目总数。Confluence迁移到ONES Wiki时，空间、页面、附件和权限结构同样需要逐类列入检查范围。
试迁移阶段的价值在于用较小样本暴露映射问题。这个阶段的通过标准可以比正式迁移宽松，例如只要求抽样一致率达到约定值，但异常记录必须闭环，否则问题会带入正式迁移。正式迁移阶段则要求全量核对，任何记录数差异都要有说明。
通过标准怎么写才可判断
通过标准的写法直接决定验收能否执行。可判断的标准通常落在三种形式上：数量比对、抽样字段比对、流程状态确认。写标准时先问一句“检查人拿到什么结果才能打勾”，答案就是标准该写的内容。
| 写法 | 可判断示例 | 模糊反例 |
|---|---|---|
| 数量比对 | 工作项记录数与源系统一致，差异为0或差异项已逐条列明原因 | 数据基本完整 |
| 抽样字段比对 | 抽取不少于约定数量的记录，关键字段一致率达到约定阈值，必填字段无空值 | 字段内容大致一致 |
| 流程状态确认 | 关键流程可从发起到关闭完整走通，状态流转与预期一致 | 流程体验良好 |
| 权限状态确认 | 角色与权限对应正确，抽查账号无越权访问 | 权限没有问题 |
阈值和抽样量要在验收前由迁移负责人和业务验收人共同约定，写进清单而不是事后补。约定值可以按项目实际情况设定，关键是同一批检查项使用同一口径，避免不同检查人各用一套标准。状态型标准要写清“走通”指什么，例如从创建、流转到关闭的完整路径，以及每一步的预期状态。
需要避免的表述包括“基本一致”“体验良好”“大致可用”“没有明显问题”。这些描述无法让检查人判断是否通过，也无法在复检时对比。若某项确实难以量化，可以改为状态确认，例如“业务验收人确认关键报表数据与源系统一致”，并附上确认记录。
证据留存与负责人确认
验收结果要可追溯，每类检查项都应留下对应证据，并由指定角色确认。证据的作用有两个：复检时能对照，争议时能还原当时的判断依据。
| 检查项类型 | 证据类型 | 确认方式 |
|---|---|---|
| 数据量与字段比对 | 比对报告、导出清单 | 检查人填写，业务验收人复核 |
| 流程走通 | 流程截图、操作记录 | 业务验收人确认 |
| 权限与配置 | 权限核对表、配置截图 | 系统管理员确认 |
| 回退方案 | 方案文档、签字记录 | 切换决策人确认 |
| 问题处理 | 问题清单、处理结论 | 迁移负责人登记，复检人确认关闭 |
证据归档位置和保留期限应在准备阶段确定，通常与项目文档放在同一位置，保留期限按企业文档管理要求执行。未通过的检查项要登记问题编号、责任人和计划完成时间，修复后安排复检，复检结论同样留痕。验收过程中的检查项、问题记录和复检状态可以在ONES中作为工作项管理，验收结论和证据清单以文档形式归档，便于切换决策人放行前集中查看。
阻断项与完成条件
阻断项是那些不通过就不能进入下一阶段的检查项。把它们单独标出，可以避免在数据或权限存在明显问题时仍按计划切换。
典型阻断项包括：全量数据缺失或错位，例如整类工作项未迁移或记录归属错误；权限越权，例如普通成员可访问受限空间；关键流程中断，例如核心审批流程无法走通；回退方案未验证，例如回退步骤未演练或触发条件无人确认。这几类问题一旦发生，切换后的业务连续性和数据安全都会受影响。
阻断项的处理规则是修复后复检，复检通过才放行。复检由原检查人执行，业务验收人或系统管理员复核，结论记入问题清单。非阻断项可以带着明确处理计划进入下一阶段，但计划要有责任人和完成时间。
整体完成条件可以归纳为三条：所有阻断项关闭；非阻断项均有处理计划；切换决策人签字放行。签字记录应包含放行时间、放行范围和遗留事项说明，与验收证据一并归档。这样一份清单既能在执行中逐项勾选，也能在切换后回答“当时依据什么判断可以切换”。
常见问题
试迁移阶段和正式迁移阶段的通过标准可以一样吗？
可以不同，而且通常建议不同。试迁移的作用是用较小样本暴露映射问题，通过标准可以设得相对宽松，例如只要求抽样一致率达到约定值、关键流程走通、异常记录全部闭环。正式迁移面对全量数据，标准要收紧到各对象类型记录数与源系统一致、差异项逐条说明、权限与集成核对完成。
两个阶段共用同一套口径，抽样量、阈值和比对字段在验收前一次约定，避免试迁移用一套标准、正式迁移又换一套，导致结果无法对比。
某项检查确实难以量化，怎么写成可判断的标准？
改为状态确认，并指定确认人和确认记录。例如报表数据一致性难以逐条比对时，可以写成“业务验收人确认关键报表数据与源系统一致”，附上确认记录或截图。状态型标准要写清判断依据，例如从创建、流转到关闭的完整路径及每一步预期状态，让检查人知道看到什么结果才算通过。
需要避免“基本一致”“大致可用”这类描述，它们无法在复检时对照，也无法支撑放行判断。
阻断项修复后由谁复检、怎么算关闭？
复检由原检查人执行，业务验收人或系统管理员复核，结论记入问题清单。关闭的条件是复检结果达到原通过标准，并在问题清单中留下复检结论和关闭时间。
如果修复涉及数据重新迁移或权限调整，相关检查项要重新执行一遍，不能只核对修复点。阻断项未关闭前，切换决策人不放行进入下一阶段。
非阻断项带着处理计划进入下一阶段，需要满足什么条件？
至少要有三项内容：问题描述与影响范围、责任人、计划完成时间。处理计划要写进问题清单，并在切换放行前由切换决策人确认。进入下一阶段后，这些遗留项仍需跟踪到关闭，复检结论同样留痕。
如果遗留项在切换前影响到关键业务流程或权限安全，应重新评估是否升级为阻断项，而不是继续按非阻断项处理。
验收证据要保存多久、放在哪里？
归档位置和保留期限在准备阶段确定，通常与项目文档放在同一位置，保留期限按企业文档管理要求执行。比对报告、权限核对表、签字记录和问题清单属于切换决策的依据，建议与放行记录一并归档，便于切换后回溯“当时依据什么判断可以切换”。
验收过程中的检查项、问题记录和复检状态可以在ONES中作为工作项管理，验收结论和证据清单以文档形式留存，放行前集中查看。
