数据迁移验收不能以“文件已导入”或“脚本已执行”为完成标志。真正的验收对象，是迁移后的数据能否在新系统中被正确识别、关联、查询和使用。因此，验收标准应在项目开始前确定，并同时覆盖数据范围、转换规则、质量结果、业务可用性和异常处理。
先定义迁移范围
验收前应形成明确的数据清单，至少说明数据来源、迁移对象、保存时间和处理方式。客户资料、未完成订单、售后记录、会员等级、积分、账户余额、当前商品与库存等核心数据，通常应列入重点验收范围。测试账号、无业务价值的日志、重复记录以及已失效的附件，则应明确是迁移、排除，还是单独保留。
范围不清，后续的“缺失数据”就无法判断究竟是迁移失败，还是原本不在项目范围内。
把验收标准写成可核对的条件
核心数据应至少从五个维度验收：
- 完整性：迁移记录是否覆盖约定的数据范围，异常记录是否有清单。
- 一致性：客户、订单、商品等关联关系是否正确，订单数量和金额是否能够核对。
- 准确性：字段映射、时间格式、订单状态、会员等级、积分和账户余额是否符合约定规则。
- 可用性：新系统能否正常搜索、查询、统计，图片和附件在迁移范围内是否可以打开。
- 安全性：权限范围是否发生异常变化，客户资料的复制、传输和访问是否受到控制。
其中，“准确率”不能只写成笼统承诺，还应说明重点字段、抽样检查比例、核对方式以及允许存在的异常类型。
验收必须覆盖迁移过程
数据迁移通常要经历测试环境导入、业务人员抽样检查、规则修正、第二轮导入和正式切换。每一轮都应保留迁移记录、异常清单和处理结果，不能只验收最后一次导入。
如果旧系统在试迁移后仍持续产生订单，还必须验收增量数据同步结果。对不能长时间停机的业务，还应提前约定切换窗口、回滚条件和失败后的处理方式，否则即使数据数量一致，也不能证明系统已经安全切换。
最终合同中应将迁移范围、字段规则、验证方法、附件处理、迁移次数、异常修复责任和验收报告分别写清。标准越具体，验收越像一次可复核的业务核对，而不是双方凭感觉判断“数据已经搬过去了”。
