一次数据迁移完成后，业务部门反馈订单数量和金额对不上。技术团队反复核对迁移脚本，发现两边记录条数一致，但部分订单的状态字段在旧系统里是“已关闭”，到了新系统却变成“已完成”。问题不在迁移工具，而在迁移前没有把字段含义盘清楚。字段盘点不是把表结构导出来看一眼，而是要把每个字段的来源、去向和业务规则对齐。it数运在企业数字化服务中，通常把这一步放在迁移方案设计之前，因为字段不清，后面的清洗和校验都无从谈起。
先盘字段名称、类型、长度与业务含义的对应关系。旧系统里叫“status”的字段，可能同时承担订单状态和支付状态两种含义；新系统若拆成两个字段，就必须明确拆分规则。类型和长度也要逐一比对，比如旧系统用文本存手机号，新系统用定长字段，带区号或空格的记录就会写入失败。建议做一张对照表，左侧列旧表旧字段，右侧列新表新字段，中间写转换规则和负责人。凡是无法一一对应的字段，先标记出来单独讨论，不要默认“差不多就行”。
接着核对必填项、默认值、枚举值和历史脏数据。旧系统可能允许某字段为空，新系统却设为必填，迁移时就要决定是补默认值、回填业务数据，还是保留为空并调整新系统约束。枚举值最容易出问题，旧系统用数字表示状态，新系统用文字，映射关系错一位，整批数据都会偏。历史脏数据要提前抽样，比如日期字段里混入“0000-00-00”，金额字段里出现负数或空字符串。处理方式通常有三种：能按规则修正的写清洗脚本，无法判断的单独导出人工确认，确实无意义的做标记后不迁移。每种处理都要留下记录，方便迁移后追溯。
然后梳理表间关联、外键与孤儿记录。旧系统里订单表关联用户表，如果用户已被删除但订单还在，这条订单就是孤儿记录。直接迁移可能导致新系统外键约束报错，或者订单挂在一个不存在的用户下。检查方法不复杂：先统计主表与从表的关联数量，再查出从表中主表不存在的记录，最后按业务重要性决定是补建用户、归档订单还是放弃迁移。关联层级多的系统，建议从最底层的基础表往上逐层核对，避免遗漏。
迁移前建议准备一份字段盘点清单，至少包含旧字段名、新字段名、类型长度、业务含义、是否必填、默认值、枚举映射、清洗规则、关联关系和责任人。责任分工上，业务方确认字段含义和枚举值，技术方确认类型长度和关联关系，数据方负责抽样验证和清洗脚本。三方签字后再进入迁移执行，比迁移后返工成本低得多。
迁移完成后要做抽样比对，不要只看总条数。按业务主键抽取一定比例记录，逐字段对比新旧值，重点看状态、金额、日期和关联字段。同时准备回滚预案，保留旧系统只读权限和迁移前完整备份，明确回滚触发条件和操作步骤。一旦发现大面积偏差，先停止写入，再按预案恢复，避免新旧数据交叉污染。字段盘点做得细，迁移后的对账才站得住。
