迁移验收需要把“迁移完成”拆成可核对的证据，而不是凭感觉判断。本文给出一份已填写的迁移验收清单示例，覆盖数据完整性、字段与状态、权限、流程通知、附件关联、报表统计以及切换与回退条件，并说明每项标准的来源和改写方法。示例中的团队、数量与阈值均为演示情景，读者可据此替换成自己的迁移范围与核对口径。
要点总览（TL;DR）
- 迁移验收把“迁移完成”拆成可核对证据：先定验收对象与三个使用时点（试迁移后、正式切换前、切换后观察期），再按数据完整性、字段与状态、权限、流程通知、附件关联、报表统计、切换与回退逐项设标准。
- 每项验收标准要写清通过标准、核对方法、证据形式和负责人；示例中状态与枚举字段全量核对、长文本抽样，权限按角色验证，回退条件写成含时间窗口、触发条件与决策人的可执行条款。
- 换项目时先按“完整迁移、只迁关键字段、不迁移”划分范围来增减验收项，通过标准从绝对数量改为“差异清单为空或差异已登记并有处置计划”，试迁移与正式验收共用编号但判定严格程度不同。
- 示例中的团队规模、记录数量与差异率均为演示情景，不构成通用阈值；数据映射设计、切换后人员推广与治理不在本文范围，具体工具能力与兼容性需另行查证。
- 验收项、证据与遗留问题需要持续留痕，可用工作项承载验收项、附件保存核对记录、遗留问题转独立工作项并指派责任人，让切换决策有据可查。
示例目标：这份验收清单要回答什么
这份清单要回答一个具体问题：一次研发管理工具迁移完成后，凭什么判定可以切换、可以关闭迁移项目。它把验收对象限定为迁移后的数据与使用状态，包括记录是否齐全、字段和状态是否对得上、权限是否按角色还原、流程与通知是否可用、附件与关联关系是否完整、报表统计是否可信，以及切换窗口内出现异常时能否按预定条件回退。
清单在三个时点使用，侧重点不同。试迁移后使用，目的是发现映射与脚本问题，允许存在已知差异；正式切换前使用，目的是确认阻断项清零、遗留问题有明确处置方案；切换后观察期使用，目的是确认真实使用中没有出现验收时未覆盖的问题。三个时点共用同一套验收项，但判定严格程度不同。
验收结论分为三种。通过指全部阻断项满足标准，一般项差异已登记并有处置计划；有条件通过指阻断项满足，但存在影响部分用户或部分数据的差异，需在约定时间内修复并复验；阻断指任一阻断项未满足，暂停切换或暂停关闭项目。判定口径要在清单开始执行前确定，避免验收时因标准解释不同产生争议。
以下示例为演示情景，不对应任何真实客户、真实项目或实测结果。示例中的团队规模、记录数量、差异条数均为便于说明而设定，不构成行业通用阈值。
完整示例：一份填好的迁移验收清单
示例背景设定：某研发团队约80人，将原有研发管理工具中的需求、任务、缺陷、迭代、附件与部分报表迁移到新平台。迁移范围包含近三年的活跃项目，历史归档项目只迁移标题与关键字段。团队指定迁移负责人一名、数据核对两人、业务代表三人，分别对应产品、研发与测试方向。以下为正式切换前一轮的已填写清单。
| 编号 | 验收项 | 通过标准（示例） | 核对方法 | 证据形式 | 负责人 | 结论 |
|---|---|---|---|---|---|---|
| A1 | 记录数量完整性 | 各工作项类型的迁移条数与源系统导出条数一致，差异为0；归档项目允许仅迁移标题，需在差异清单中列明 | 源系统导出计数与新系统按类型计数逐项比对 | 两侧计数对照表、差异清单 | 数据核对员 | 通过 |
| A2 | 字段与状态一致性 | 全量核对状态字段与关键枚举字段；其余文本字段按每类型不少于30条抽样，抽样差异率不高于2%，且无状态错位 | 导出字段对照，抽样逐条比对 | 抽样记录表、差异条目截图 | 数据核对员 | 有条件通过：2条历史任务状态停留在旧枚举值，已登记 |
| A3 | 权限与可见性 | 按角色核对：项目管理员、普通成员、只读访客、外部协作人员四类角色，各自可见范围与源系统一致；无越权可见 | 每类角色各选2个账号登录验证，检查项目列表、工作项详情与附件可见性 | 角色验证记录、越权问题清单 | 业务代表 | 通过 |
| A4 | 流程与通知 | 核心流程的状态流转可正常执行；状态变更、指派、评论三类通知能送达对应角色；通知内容包含工作项标题与跳转入口 | 在试迁移环境走一遍完整流程，检查通知接收记录 | 流程走查记录、通知截图 | 业务代表 | 通过 |
| A5 | 附件与关联关系 | 附件数量与源系统一致，随机抽取50个附件可正常打开；需求与任务、缺陷与迭代的关联关系抽样核对无缺失 | 附件计数比对加抽样打开；关联关系按项目抽样比对 | 附件核对表、关联关系抽样表 | 数据核对员 | 有条件通过：3个附件因源文件损坏无法打开，已记录原文件名与所属工作项 |
| A6 | 报表与统计 | 迭代燃尽、缺陷分布、工作量统计三类报表的统计口径与源系统一致；同一时间范围内数值差异可解释 | 选取两个已完成迭代，两侧报表数值对照 | 报表对照表、口径说明 | 业务代表 | 通过 |
| A7 | 切换窗口与回退条件 | 切换窗口内旧系统只读、新系统可写；出现阻断问题时可在约定时间内恢复旧系统写入；回退触发条件与决策人明确 | 切换前演练一次回退流程，记录耗时 | 切换方案、回退演练记录 | 迁移负责人 | 通过 |
整体结论填写为“有条件通过”：阻断项A1、A3、A4、A6、A7全部满足；A2与A5存在已登记的差异，需在切换后两周内完成修复并复验。遗留问题记录采用统一格式：问题编号、所属验收项、影响范围、责任人、计划完成时间、复验结论。复验未通过的问题升级为阻断项，由迁移负责人决定是否暂停相关模块的使用。
逐项解释：每个验收项为什么这样定
数据完整性为什么先比数量
记录数量是最容易取得、也最容易产生争议的证据。取数口径必须写清楚：按工作项类型分别计数，计数时间点统一到切换前最后一次同步，源系统与新系统使用相同的过滤条件，例如是否包含已删除、是否包含归档项目。口径不一致会让“差异为0”变成无法验证的口号。数量一致只能证明没有整批丢失，不能证明内容正确，因此它通常作为第一道门槛，与字段核对配合使用。
字段与状态一致性：全量与抽样的取舍
状态、优先级、所属迭代这类枚举字段影响流程和报表，适合全量核对；描述、备注等长文本字段逐条比对成本高，适合抽样。示例中把“状态错位”单独列为不可接受项，原因是状态错误会直接导致流程卡住或报表失真，而文本字段的个别差异通常不影响使用。抽样数量要写进标准，否则验收时容易因抽多抽少产生分歧。抽样发现差异后，应扩大抽样或转为全量核对，而不是仅记录差异了事。
权限为什么按角色验收
按账号逐个核对在人数多时不可行，也无法覆盖人员变动后的情况。按角色验收的逻辑是：先确认角色定义与源系统对应，再验证每类角色的可见范围。重点检查两类问题，一是越权可见，例如外部协作人员看到内部项目；二是权限缺失，例如项目管理员无法管理成员。验收时要使用真实角色配置，而不是临时授予管理员权限的测试账号，否则验证结果不能代表切换后的实际状态。
流程、通知与附件关联怎么验证
流程验证要覆盖一条完整路径，从创建、流转到关闭，观察每个状态节点是否可执行、必填项是否生效。通知验证要区分触发条件与接收对象，状态变更、指派、评论是三类常见触发，接收对象要覆盖被指派人、关注人和项目管理员。附件与关联关系的验证重点是“引用是否还在”：附件能否打开、关联的工作项是否指向正确记录。关联关系断裂往往不会报错，只会在使用时才被发现，因此抽样要覆盖跨项目关联和跨类型关联。
切换窗口与回退条件写成可执行条款
可执行条款包含四个要素：时间窗口、系统状态、触发条件、决策人。例如“切换窗口为周六20:00至次日8:00，期间旧系统只读；若出现阻断项清单中的任一问题且30分钟内无法定位原因，由迁移负责人决定回退；回退操作需在1小时内恢复旧系统写入”。回退条件要提前演练，记录实际耗时，演练结果本身也是验收证据。没有演练过的回退方案，在真正需要时往往无法按时完成。
验收执行过程中，验收项、证据与遗留问题需要持续留痕。以ONES工作项承载每条验收项，把通过标准写在描述中，核对记录与截图作为附件，遗留问题转为独立工作项并指派责任人，验收结论与复验结果在文档中汇总，可以让切换决策有据可查，也便于观察期内追踪未关闭事项。
可迁移规律：换一个迁移项目怎么改这份清单
换项目时，先改范围，再改验收项。把迁移对象按“必须完整迁移、只需迁移关键字段、不迁移”三类划分，必须完整迁移的对象对应完整性与一致性验收项，只需关键字段的对象降低抽样要求，不迁移的对象在清单中明确排除，避免验收时被追问。范围变化会直接决定验收项增减，例如迁移范围包含工时数据时，需要增加工时与人员对应关系的验收项；不包含报表时，报表验收项可以删除而不是保留为“不适用”。
通过标准的写法建议从绝对数量改为可核对差异清单。绝对数量在不同规模的项目中难以复用，而“差异清单为空”或“差异均已登记且有处置计划”这类标准可以跨项目使用。具体做法是：先定义什么算差异，再规定差异的记录格式与处置时限，最后规定哪些差异属于阻断。这样即使迁移规模变化，判定逻辑仍然成立。
证据与负责人随组织分工调整。小团队中数据核对与业务验证可能由同一人承担，此时要在清单中注明复核方式，避免自核自验；大团队中按业务域拆分负责人，每个验收项只设一名主责人，避免多头确认。证据形式也应匹配团队现有的记录习惯，截图、导出表、走查记录都可以，关键是能回溯到具体验收项。
试迁移与正式验收使用两轮清单，差异在于判定严格程度与关注点。试迁移轮允许较多差异，重点是发现映射错误和脚本问题，验收项可以更细；正式轮只关注阻断项是否清零、遗留问题是否有处置方案，清单可以合并同类项。两轮清单共用编号体系，便于对比同一验收项在两轮中的结论变化。
适用边界：哪些情况这份示例不直接适用
示例中的阈值、团队规模与差异条数仅用于演示填写方式，不构成通用标准。不同系统的数据模型、字段数量和业务复杂度差异很大，直接套用“差异率不高于2%”这类数字，可能过松或过严。读者应结合自身迁移范围、数据量和业务容忍度重新设定，并在验收前与相关方确认。
本文聚焦迁移结果的验证与切换风险控制，数据映射设计本身不在讨论范围。字段如何对应、枚举值如何转换、脚本如何编写，属于迁移实施阶段的工作，验收清单只检查结果是否符合预期。切换后的人员推广、培训与治理同样不在本文范围，这些工作影响迁移后的实际使用效果，但不属于验收判定本身。
涉及具体工具的能力、版本与兼容性时，需要另行查证。示例中的验收项按通用研发管理对象设计，实际执行时要确认目标系统是否支持相应的字段类型、权限模型、通知机制与报表口径。工具能力差异会影响验收项的写法与证据形式，这部分应以实际环境的验证结果为准。
常见问题
试迁移和正式切换前的验收，可以用同一份清单吗？
可以共用同一套验收项和编号，但判定严格程度不同。试迁移轮允许存在较多差异，重点是发现字段映射错误和脚本问题，验收项可以拆得更细；正式切换前一轮只关注阻断项是否清零、遗留问题是否有明确处置方案，同类项可以合并。两轮共用编号的好处是能直接对比同一验收项在两轮中的结论变化，复验时也便于追溯。
迁移数据量很大时，字段一致性必须全量核对吗？
按字段性质区分。状态、优先级、所属迭代这类枚举字段会影响流程流转和报表统计，建议全量核对；描述、备注等长文本字段逐条比对成本高，可以抽样。抽样数量和抽样规则要提前写进通过标准，避免验收时因抽多抽少产生分歧。抽样发现差异后，应扩大抽样范围或转为全量核对，而不是只登记差异就结束。
回退条件写到什么程度才算可执行？
至少包含四个要素：时间窗口、系统状态、触发条件、决策人。例如明确切换窗口内旧系统只读、新系统可写，出现哪类阻断问题且在多长时间内无法定位原因时启动回退，由谁做决定，回退操作需在多长时间内恢复旧系统写入。回退方案要在切换前实际演练一次并记录耗时，演练记录本身也是验收证据；未演练过的回退方案在真正需要时往往难以按时完成。
验收时发现差异，什么情况算阻断、什么情况可以有条件通过？
判定口径要在清单执行前确定。通常把影响流程执行、权限边界或报表可信度的差异列为阻断，例如状态错位、越权可见、核心流程无法流转；影响部分数据但不妨碍整体使用的差异可以登记为遗留问题，给出修复时限与复验安排，结论记为有条件通过。复验未通过的问题应升级为阻断项，由迁移负责人决定是否暂停相关模块使用。
小团队人手少，验收人和执行人重合怎么办？
可以在清单中注明复核方式，例如数据核对由一人执行、另一人抽查复核，或由业务代表对关键验收项做二次确认，避免自核自验。负责人一栏每个验收项只设一名主责人，复核人单独列出。证据形式按团队现有记录习惯选择，截图、导出表、走查记录都可以，关键是能回溯到具体验收项和核对时间。
