迁移验收清单和业务验收记录的分工，可以用一句话概括：清单由迁移项目组逐项核对“数据、配置、权限、集成是否按约定迁到位”，记录由业务方确认“迁移后能否正常开展业务并签署留痕”。前者是技术核验的执行工具，后者是业务确认的证据。本文界定两者的范围边界，并说明它们与迁移测试报告的衔接方式，帮助迁移项目在切换前后正确分工、避免用清单打勾代替业务验收。
要点总览（TL;DR）
- 迁移验收清单由迁移项目组使用，逐项核对数据、配置、权限、集成是否按约定迁到位，回答“技术迁移结果是否符合约定”。
- 业务验收记录由业务方签署，确认迁移后关键业务场景能否正常开展，回答“业务是否可用、由谁确认”。
- 迁移测试报告提供验证依据，清单据此逐项核对，清单结果再作为业务验收记录的证据附件。
- 清单打勾只说明技术核对项通过，业务方是否接受仍需独立确认；记录缺少清单支撑时，追溯会失去技术事实依据。
一句话说清两者的分工
迁移验收清单是迁移项目组在切换前后使用的逐项检查表，核心问题是“技术迁移结果是否符合约定”。它把迁移方案中承诺的内容拆成可核对的条目，由执行迁移或负责验证的人员逐条确认，产出形态是一份带核对结论的清单，通常标注每条的状态、核对人和核对时间。
业务验收记录是业务方在真实业务场景中确认迁移结果可用的签署性证据，核心问题是“业务是否可用、由谁确认”。它由业务负责人或关键用户参与，产出形态是一份包含验收场景、参与角色、确认结论和签署时间的记录，具有确认和留痕性质。
两者的差异集中在三个维度：责任主体上，清单由迁移项目组负责，记录由业务方负责；回答问题上，清单回答技术是否迁到位，记录回答业务是否可用；产出形态上，清单是执行工具，记录是确认结果。清单的核对结论可以作为记录的证据附件，但清单本身不产生业务方的接受结论，因此不能互相替代。缺少记录，迁移完成缺少业务侧的确认依据；缺少清单，业务确认缺少逐项技术事实的支撑。
迁移验收清单覆盖什么、不覆盖什么
清单的范围应围绕“迁移约定是否落地”展开，典型条目包括：数据完整性，即源端与目标端的记录数量、关键字段值是否一致；字段映射结果，即原字段在新平台中的对应关系是否符合映射设计；权限与角色，即原有角色、权限分配是否按约定重建；附件与关联关系，即附件是否完整迁移、工作项之间的关联是否保留；集成连通性，即与周边系统的接口、 webhook、单点登录等是否可用。这些条目共同指向一个判断：迁移动作本身是否按方案执行到位。
清单的使用时点分为两段。切换前预检用于确认迁移环境、映射规则、回滚条件和抽样数据，属于准备工作核对；切换后核对用于确认正式迁移结果，逐项记录通过、不通过或待处理。两段清单可以共用条目结构，但核对对象和判定标准不同，应在清单上明确区分。
清单不承担的内容需要明确排除：业务可用性判断不属于清单，因为“数据迁到了”与“业务能顺畅开展”是两个判断；业务方签署不属于清单，签署动作发生在业务验收环节；推广与培训安排也不属于清单，那属于切换后的运营工作。此外，清单与迁移测试报告的关系是：测试报告提供验证依据和结论，清单据此做逐项核对，清单引用报告结果，不重复测试过程。
业务验收记录覆盖什么、不覆盖什么
业务验收记录的典型构成包括：验收场景，即业务方实际走通的业务流程或典型操作；参与角色，即哪些业务岗位参与了确认；确认结论，即接受、有条件接受或不接受；遗留问题与处理约定，即尚未解决的问题、责任人和计划完成时间；签署时间，即确认发生的时点。这些要素共同构成一份可追溯的业务确认证据。
记录回答的是业务可用性与接受度：迁移后的平台能否支撑日常业务操作，关键场景是否走通，业务方是否愿意在此状态下切换。它由业务方主导，迁移项目组提供清单、测试报告等材料作为参考。
记录不承担的内容同样需要划清：逐条技术核对不属于记录，那是清单的职责；数据映射设计不属于记录，属于迁移方案范畴；迁移脚本验证不属于记录，属于技术测试范畴。记录与迁移测试报告的区别在于：测试报告偏技术验证过程，说明测了什么、结果如何；记录偏业务确认结果，说明业务方看了什么、确认了什么。两者可以互相引用，但结论主体不同。
清单、测试报告、验收记录如何衔接
三者在迁移验证流程中形成“依据—核对—确认”的链条，衔接机制可以按以下顺序落地：
- 迁移测试完成后形成测试报告，记录测试范围、用例、结果和已知问题，作为后续核对的依据。
- 迁移项目组依据测试报告和迁移方案编制验收清单，在切换前预检和切换后核对两个时点逐项执行，记录每条的状态和证据位置。
- 清单核对完成后，将清单结果作为业务验收记录的证据附件提交给业务方，业务方结合真实场景操作形成确认结论并签署。
- 业务验收记录中提出的遗留问题回流到清单或问题跟踪中，形成待办，明确责任人和处理时限，处理结果再补充进记录或后续核对。
时点顺序上，测试报告最早，清单核对居中，业务验收记录在业务方确认后形成。交接节点应明确：清单何时冻结提交、业务验收何时启动、遗留问题何时关闭。组织可以将这些节点纳入变更管理或质量门禁，具体形式依自身制度调整。
在工具承载上，清单的逐项核对和记录的签署留痕可以在同一工作项与文档流程中完成：核对条目作为工作项逐条流转状态，验收记录作为文档关联清单结果并保留签署信息，便于后续追溯。ONES 的迁移方案围绕项目、工作项、状态、字段、流程、附件和历史记录进行迁移，并把数据完整、业务连续和系统稳定作为迁移目标，这类迁移范围可以作为编制清单条目的参考；验收清单与记录的具体承载形态需结合团队实际流程设计。
一个迁移场景中的具体划分示例
以下为演示情景：某研发团队从旧的项目管理工具迁移到新平台，迁移范围包括工作项、状态流转、自定义字段、附件和与代码仓库的关联。
清单条目示例与核对结果可以这样呈现：数据完整性条目核对源端与目标端工作项总数一致，结论为通过；字段映射条目核对优先级、负责人等自定义字段的对应关系，发现一个枚举值未映射，结论为不通过并记录待处理；权限与角色条目核对项目角色分配，结论为通过；附件与关联关系条目核对附件数量和代码提交关联，结论为通过；集成连通性条目核对代码仓库 webhook，结论为通过。清单由此形成一份带状态的技术核对结果。
业务验收记录则围绕场景展开：业务方选择“需求创建到上线”的完整流程进行确认，参与角色包括产品经理、研发负责人和测试负责人；确认结论为有条件接受，条件是未映射的枚举值在两周内修正；遗留问题与处理约定记录该枚举值的修正责任人和时限；签署时间记录确认日期。同一枚举值问题在清单中表现为一条不通过条目及证据位置，在记录中表现为接受条件和遗留问题，两者指向同一事实但承担不同功能。
常见误解是把清单全部打勾当作业务验收完成。清单通过只说明技术核对项符合约定，业务方是否接受、关键场景是否走通仍需独立确认。另一个误解是用业务验收记录替代清单，记录中的结论缺少逐项技术事实支撑时，后续排查和追溯会失去依据。正确做法是让清单提供事实、记录提供结论，两者各自留痕、互相引用。
常见问题
迁移验收清单和业务验收记录可以由同一个人签署吗？
可以，但需要区分签署身份和签署内容。同一个人如果既负责迁移执行又代表业务方，在清单上签的是“技术核对结果”，在记录上签的是“业务接受结论”，两个动作的判断依据不同。实际操作中建议在记录中注明签署人同时承担的角色，避免后续追溯时把技术核对结论误读为业务确认。若组织要求职责分离，可由迁移项目组核对清单、业务负责人签署记录，形成相互印证。
切换后发现清单漏项，业务验收记录已经签署，应该怎么处理？
先评估漏项影响的是技术事实还是业务结论。若漏项属于技术核对范围、不影响业务可用性，可补充清单条目并注明补录原因和时间，记录保持有效；若漏项可能导致业务场景不可用，应启动记录中的遗留问题流程，由业务方重新确认受影响场景，必要时修订验收结论。补录和修订都应保留原始版本，便于审计追溯。
小团队迁移也需要同时保留清单和记录吗？
取决于迁移风险和留痕要求。迁移范围小、参与人少、切换可快速回滚时，可以把清单和记录合并为一份文档，但要在文档中分栏标明技术核对项和业务确认结论，保留两类信息。迁移涉及核心业务数据、多系统集成或外部合规要求时，建议分开留存，因为两者的责任主体和证据用途不同，合并后容易在追溯时混淆。
业务验收记录中的“有条件接受”与清单中的“不通过”是什么关系？
两者可以指向同一事实，但功能不同。清单中的“不通过”是技术核对结论，说明某一项未达到约定标准并记录证据位置；记录中的“有条件接受”是业务判断，说明业务方在知晓该问题的前提下同意切换，并约定修正条件和时限。记录引用清单条目作为依据，清单不因记录签署而自动变为通过，修正完成后应回到清单更新状态。
迁移测试报告已经覆盖的内容，验收清单还需要重复核对吗？
不需要重复测试过程，但需要逐项确认测试结论是否覆盖迁移约定。测试报告说明测了什么、结果如何，清单则把迁移方案中的承诺逐条对应到报告结论或补充核对证据，标注每条的状态和证据位置。清单的价值在于形成可逐项追溯的核对记录，测试报告提供依据，两者分工不同。
