数据迁移验证应覆盖来源范围、字段映射、转换规则、批次结果、异常处置与业务抽查，避免只以导入完成判断迁移成功。
企业软件切换时，数据导入完成并不等于迁移已经可靠。旧系统中的编码、状态、关联关系和历史口径，常常与新系统的结构不同。若只看导入条数，业务人员可能在正式使用后才发现客户重复、未结事项缺失或历史记录被错误归类。迁移工作应把数据范围、转换规则、批次结果和业务确认连接起来。
先说明迁移目的与数据边界
开始前应明确哪些对象必须迁移、哪些仅供查询、哪些可以归档，以及新系统从哪个时间点承担主记录职责。客户、供应商、合同、订单、库存或服务事项等对象的边界不同，不能简单按数据库表逐一搬运。每类数据还应注明来源系统、提取时点、责任角色和保留规则，避免后续无法解释某条记录为何不存在。
字段映射不仅是两列名称对照
映射表至少应记录来源字段、新字段、转换方式、默认值、必填要求、枚举值对应关系和异常处理原则。例如旧系统的“已完成”可能要根据不同完成原因映射到新系统的多个状态；合并后的客户名称则需要保留原始标识以支持回查。对无法直接转换的字段，应明确是补录、置空、归档还是不迁移，不能在执行时临时猜测。
把清洗、转换和装载分开留痕
重复记录合并、格式修正、无效值排除等清洗动作，应保留规则和影响范围。转换过程需要使用可重复执行的版本，而不是仅保留一次性手工表格；装载时则记录批次编号、执行时间、输入文件或提取范围、执行人和返回结果。这样在发现问题时，团队可以定位是源数据、转换规则还是写入环节造成差异。
校验同时看数量、关系和业务含义
数量核对是基础，例如来源记录数、符合条件数、成功写入数和拒绝数是否一致。但仅核对总数不足以发现关联错误，还应检查主从关系、状态分布、关键金额或日期范围、唯一编号和必填字段。对重要对象，可以抽取覆盖边界状态、历史记录、异常值和关联链路的业务样本，由熟悉规则的人员确认显示和后续流程是否符合预期。
异常记录要有可处理的出口
导入失败、字段不满足规则、关联对象缺失或重复匹配时，不应只在技术日志中留下错误。将异常记录汇入清单，列明原因分类、原始标识、建议处理方式、责任人和处理状态，便于业务与技术人员共同判断。修复后应重新校验并保留关联批次，避免把手工补录与原始迁移结果混在一起。
正式切换前确认增量与回退条件
测试迁移结束到正式切换之间，旧系统仍可能产生新增或变更数据。团队需要确定增量提取窗口、暂停录入安排、对账责任和最终确认节点。若关键校验未通过，应依据预先约定的条件继续修正、延期切换或恢复原流程；回退计划要考虑已在新系统产生的数据，不能只把旧数据重新导入。
迁移后保留一段可查询的对照期
上线初期，业务人员会遇到需要对照历史记录的情况。可在受控范围内保留旧系统查询入口或归档数据，并提供新旧编号的对应查询方式。对照期内收集的差异，应区分真实迁移缺陷、原始数据问题和新系统操作理解差异，再按责任归类处理。完成确认后，及时关闭不再需要的写入入口，避免形成双主数据源。
常见问题
历史数据是否必须全部迁移？
不一定。应根据业务连续性、查询需求、合规要求和迁移风险确定范围；不迁移的数据也需要有可靠的归档与查询安排。
迁移校验通过后还需要业务抽查吗？
需要。技术校验能发现格式和数量问题，业务抽查才能确认状态、关联和使用场景是否被正确理解。
发现少量异常能否先上线再处理？
应结合异常对象的重要性、影响范围和临时控制措施判断。涉及关键业务、金额、权限或未结事项的异常，不宜只因数量少而忽略。