迁移验收要回答的核心问题，是切换前能否放行。本文用一套虚构的“研发管理工具迁移”情景，给出一份填好的验收清单：从试迁移、数据完整性与附件校验、业务验收、并行运行到切换窗口与回退，逐项写明检查项、通过标准、证据材料和负责人，并解释每个字段为什么这样填，方便你替换成自己的迁移对象直接参照。
要点总览（TL;DR）
- 迁移验收清单按试迁移、完整性与附件校验、业务验收、并行运行、切换窗口与回退六个环节组织，每项写清检查项、通过标准、证据、负责人和结论。
- 通过标准要能用数量、比例或明确状态判定，例如字段映射正确率不低于98%、附件下载成功率100%，避免“基本一致”这类模糊表述。
- 证据要能对应具体检查项并留存可追溯，条数核对配统计报表，界面状态配截图，责任确认配签字。
- 回退条件写成可观测的触发阈值，如数据丢失、主流程不可用或切换超时2小时以上，阈值结合切换窗口长度设定。
- 换项目时保留六环节骨架与五列结构，按迁移对象替换检查项，按出错代价调整并行时长与回退演练深度。
示例目标：这份验收清单要回答什么
先交代情景。某研发团队要把需求、缺陷、迭代、文档和附件从旧研发管理工具迁移到新平台，计划在某个周末的维护窗口完成切换。切换前，项目组需要一次正式的验收评审，判断“能不能放行”。本文的清单就是为这次评审准备的，所有团队名称、数据量、时间均为虚构示例，不对应任何真实客户或实测结果。
清单围绕三个判断问题展开：
- 数据是否完整：该迁的记录是否都在，字段是否可用，附件能否打开。
- 业务是否可用：关键流程能否在新平台走通，权限与角色是否按预期可见。
- 出问题能否回退：切换窗口内出现异常时，是否有明确的回退触发条件和可执行的回退路径。
这三个问题对应三种放行结论：全部满足则按计划切换；部分项不满足但风险可控，可带条件放行并约定补验时间；关键项不满足则推迟切换。清单的价值在于把“感觉差不多”变成可逐项核对的记录，让评审有据可依。
示例情景卡如下，便于对照后文表格：
| 要素 | 示例设定 |
|---|---|
| 迁移对象 | 需求、缺陷、迭代、文档及附件、用户与角色 |
| 迁移范围 | 近三年活跃项目，历史归档项目只迁索引 |
| 时间窗口 | 周六 22:00 至周日 06:00，共 8 小时 |
| 放行决策 | 验收评审会决定：按期切换、带条件放行或推迟 |
完整示例：一份填好的迁移验收清单
下表是填好的示例清单，覆盖六个验收环节。结论列填写“通过”“带条件通过”或“不通过”，带条件通过需在备注中写明补验项与时限。示例数据仅用于演示填写方式。
| 环节 | 检查项 | 通过标准 | 证据材料 | 负责人 | 结论 |
|---|---|---|---|---|---|
| 试迁移 | 样本范围覆盖 | 抽取 3 个代表性项目，覆盖需求、缺陷、迭代、文档四类对象 | 样本清单及抽取说明 | 迁移实施负责人 | 通过 |
| 试迁移 | 字段映射结果抽查 | 每类对象抽查 50 条，字段映射正确率不低于 98% | 抽查比对表（旧系统导出与新系统导出并列） | 数据迁移工程师 | 通过 |
| 试迁移 | 问题闭环 | 试迁移发现的阻断级问题全部关闭，一般问题有处理计划 | 问题清单及关闭记录 | 测试负责人 | 带条件通过：2 项一般问题约定切换后一周内修复 |
| 完整性校验 | 记录条数核对 | 各类对象迁移条数与源系统导出条数一致，差异为 0 | 源端与目标端条数统计报表 | 数据迁移工程师 | 通过 |
| 完整性校验 | 关键字段非空率 | 标题、状态、负责人、创建时间等关键字段非空率 100% | 字段非空率统计报表 | 数据迁移工程师 | 通过 |
| 完整性校验 | 附件可下载与可预览 | 随机抽取 100 个附件，下载成功率 100%，常见格式可在线预览 | 附件抽检记录及失败清单 | 测试负责人 | 通过 |
| 业务验收 | 关键流程走通 | 需求提出到关闭、缺陷提交到验证关闭两条主流程在新平台完整走通 | 流程走查记录及截图 | 业务代表 | 通过 |
| 业务验收 | 权限与角色可见性 | 抽取 5 个角色，各角色可见范围与旧系统一致，越权访问为 0 | 角色权限对照表及验证记录 | 系统管理员 | 通过 |
| 并行运行 | 双轨时长与差异比对 | 新旧系统并行 5 个工作日，每日比对新增记录，差异当日清零 | 每日差异比对记录 | 项目经理 | 通过 |
| 切换窗口 | 冻结时间 | 切换前 4 小时停止旧系统写入，冻结通知已送达全部使用团队 | 冻结通知及确认回执 | 项目经理 | 通过 |
| 切换窗口 | 回退触发条件 | 出现数据丢失、主流程不可用或切换超时 2 小时以上，任一条件触发即启动回退 | 回退预案文档 | 技术负责人 | 通过 |
| 切换窗口 | 回退演练结果 | 切换前完成一次回退演练，回退耗时不超过 1 小时，数据可恢复至演练前状态 | 演练记录及耗时统计 | 技术负责人 | 通过 |
这张表可以直接作为评审会的核对底稿：逐行确认结论，带条件通过的项写明补验责任人和时限，最后由项目经理与技术负责人签字，形成放行记录。验收结论与放行决策绑定后，后续出现争议时有据可查。
逐项解释：每个字段为什么这样填
表格看起来简单，填写质量差别主要在“通过标准”和“证据材料”两列。下面按字段说明示例的填写依据。
通过标准要可判定
可判定的标准能用数量、比例或明确状态回答“过还是不过”。示例中“字段映射正确率不低于 98%”“附件下载成功率 100%”“越权访问为 0”，评审时只需看报表数字即可下结论。反过来，“数据基本一致”“流程基本顺畅”这类表述，不同人理解不同，评审容易变成争论。填写时可以先问自己：换一个人拿着这条标准去核对，能不能得出同一个结论。如果不能，就把它改写成可计数的指标。
证据要可复核
证据的作用是让没参与执行的人也能验证结论。示例中使用的证据包括源端与目标端的条数统计报表、抽查比对表、附件抽检记录、流程走查截图和签字确认。选择证据时注意两点：一是证据要能对应到具体检查项，比如条数核对配统计报表，而不是一份笼统的“迁移报告”；二是证据要留存到可追溯的位置，评审后仍能调取。截图适合证明界面状态，报表适合证明数量关系，签字适合证明责任确认，三者用途不同。
负责人要落到具体角色
示例中负责人写的是“数据迁移工程师”“测试负责人”“业务代表”“系统管理员”等角色，而非“数据组”“业务部门”。落到角色的好处是责任清晰、便于追人；如果团队较小一人多岗，可以在角色后加姓名。需要说明的是，负责人是该项检查的执行与举证责任人，放行决策仍由评审会集体做出，两者不要混为一谈。
回退条件要写成触发阈值
“出问题就回退”无法执行，因为“问题”没有边界。示例把回退条件写成三类可观测的触发阈值：数据丢失、主流程不可用、切换超时 2 小时以上。阈值需要结合切换窗口长度设定，窗口 8 小时而超时阈值 2 小时，意味着留出足够时间执行回退。回退演练结果同样要量化，示例要求回退耗时不超过 1 小时，这个数字来自演练实测，而非拍脑袋，填写时应以本团队演练数据为准。
可迁移规律：换一个迁移项目怎么改
这份清单的结构可以复用，内容需要按项目替换。可迁移的部分是六环节骨架和“检查项、通过标准、证据、负责人、结论”五列结构；需要替换的是具体检查项、阈值和证据形式。
- 按迁移对象替换检查项：迁代码仓库时，检查项换成仓库数量、提交历史完整性、分支与标签保留；迁需求与缺陷时，关注状态流转和关联关系；迁文档与附件时，重点在附件可下载可预览；迁权限关系时，核对角色、成员与可见范围。
- 按风险高低调整并行时长与演练深度：核心业务系统、数据量大、回退成本高的迁移，并行运行时间可以拉长到两周以上，回退演练做全量演练；内部辅助工具、数据量小的迁移，并行三到五天、做一次抽样回退演练即可。调整的依据是“出错的代价”，而非统一规定。
- 把验收结论与放行决策绑定：清单填完后要有明确的收口动作，例如评审会逐项确认、形成签字或审批记录。没有收口动作的清单容易停留在文档层面。
如果团队在工具里管理迁移过程，可以把每个检查项建成工作项，把通过标准写进验收字段，证据作为附件挂在工作项上，评审结论通过状态流转和评审记录留痕。ONES 的工作项状态与评审记录可以承载这类验收过程，让清单从静态表格变成可跟踪的执行记录；具体字段配置按团队实际流程设定。
适用边界：这份示例不覆盖什么
这份示例的定位是“结果校验与切换风险控制”的填写示范，使用时注意以下边界。
- 示例数据为虚构：文中团队、数据量、时间窗口和结论均为演示设定，不代表任何真实项目的迁移结果或效果。
- 不涉及数据映射规则设计：字段怎么对应、值怎么转换、历史脏数据怎么处理，属于迁移方案设计环节，本文只校验映射结果，不讨论映射规则本身。
- 不覆盖切换后的人员推广与治理：培训、使用推广、上线后的运营机制是切换后的独立工作，不在验收清单范围内。
- 具体工具的兼容版本、接口能力与认证需另行查证：不同工具的导入导出格式、API 限制和版本要求会直接影响迁移可行性，应以工具官方文档和实际测试为准。
把清单当作核对底稿而非万能模板，结合本项目的迁移对象、风险等级和切换窗口调整阈值与证据形式，验收结论才站得住。
常见问题
并行运行时间应该设多长，差异比对怎么做才有意义？
并行时长取决于出错的代价。核心业务系统、数据量大、回退成本高的迁移，可以并行两周以上；内部辅助工具、数据量小的迁移，并行三到五个工作日即可。比时长更重要的是比对方式：每天固定时间导出新旧系统的新增记录，按对象类型逐项比对，差异当日记录、当日清零，并保留每日比对记录作为验收证据。如果差异持续累积无人处理，并行时间再长也说明不了问题。
带条件放行时，补验项应该怎么约定才不至于拖成遗留问题？
带条件放行需要同时写清三件事：补验的具体检查项、补验责任人和完成时限。示例中“2项一般问题约定切换后一周内修复”就是这种写法。建议在评审记录中把补验项单独列出，指定跟进人，并在到期时回到清单上更新结论。补验项应限于不影响主流程可用和数据完整的一般问题；涉及数据丢失或主流程不可用的项，按不通过处理，推迟切换。
回退演练要演练到什么程度才算有效？
有效的回退演练至少验证两件事：回退路径能走通，回退耗时在可接受范围内。示例要求切换前完成一次回退演练，回退耗时不超过1小时，数据可恢复至演练前状态。演练深度随风险调整：核心系统做全量演练，辅助工具可做抽样演练。演练记录要留下耗时统计和恢复后的数据核对结果，作为切换窗口内启动回退时的依据。演练中发现的路径问题应在正式切换前修复并复演。
清单填完后，验收结论如何与放行决策衔接？
清单需要收口动作，否则容易停留在文档层面。常见做法是召开验收评审会，逐行确认结论，带条件通过的项写明补验责任人和时限，最后由项目经理与技术负责人签字，形成放行记录。放行记录与清单一起归档，后续出现争议时可追溯。如果团队在工具中管理迁移过程，可以把检查项建成工作项，通过标准写进验收字段，证据作为附件挂在工作项上，评审结论通过状态流转和评审记录留痕。
迁移对象不同，检查项要改哪些地方？
六环节骨架和五列结构可以保留，检查项按对象替换。迁代码仓库时，检查仓库数量、提交历史完整性、分支与标签保留；迁需求与缺陷时，关注状态流转和关联关系是否保留；迁文档与附件时，重点在附件可下载可预览；迁权限关系时，核对角色、成员与可见范围是否与旧系统一致。阈值和证据形式也随对象调整，例如代码仓库的比对以提交记录为准，附件的比对以抽检记录为准。
