系统迁移时，旧数据库导出的客户信息往往带着一堆“历史痕迹”：字段名是拼音首字母缩写，手机号中间夹着空格，日期被写成“二〇二三年三月”这样的中文格式，地址栏里省市区和门牌号挤在一起。直接导入新系统，结果姓名跑进备注栏，手机号被截成十位，金额小数点后少了一位。这时候最常见的提议是“先写个转换脚本跑一遍”，但脚本写得越急，后面返工越多。字段对不上，根子上是业务口径没统一，梳理顺序比技术手段更关键。
第一步不是敲代码，而是做字段清单对照。把旧系统导出的每一列和新系统要求的每一列并排列出来，逐项填四件事：字段名、业务含义、是否必填、两三条真实示例值。名字不同但含义相同的，这一步就能对上；名字相同但含义不同的，也能及时暴露。比如旧系统叫“客户编号”，新系统叫“客户ID”，看着像一回事，但示例值一个是八位数字、一个是带字母的十二位编码，那就说明编码规则变了，不能直接映射。这张表要拉着业务方一起确认，技术方单方面判断容易想当然。
第二步处理格式差异。日期、手机号、金额、地址是最容易出问题的四类。日期要统一成目标系统接受的格式，同时确认时区问题；手机号要决定是否保留国际区号、是否清洗空格和横线；金额要确认单位是元还是分、是否含税；地址要决定拆分到哪一级。这里有一条原则：纯格式问题可以由技术方按规则批量处理，涉及业务含义的差异必须由业务方拍板。比如旧系统里“金额”一栏有的记录是含税价、有的是不含税价，这种差异脚本判断不了，只能由业务方给出统一口径，否则导入后财务报表一定对不上。
第三步处理一对多和缺失值。旧系统一个“联系方式”字段里可能塞了电话、邮箱、微信三样东西，新系统要求分成三个独立字段，这就需要拆列规则，并明确拆不出来时怎么填。反过来，新系统必填但旧数据为空的字段，不能简单填个默认值了事，要逐类记录：是历史数据本身就没采集，还是导出时漏了，还是业务上允许为空。每一类缺失都要有处置结论，是补录、是留空标记、还是走人工确认，都要写清楚，否则全量导入后会出现大量看似正常实则无意义的记录。
第四步做小批量试导和抽样核对。不要一上来就全量跑。先挑几十条典型记录，覆盖正常值、边界值、缺失值、格式异常值，导入测试环境后逐条比对。核对时重点看三类问题：字段是否错位、格式是否被截断、必填项是否被错误填充。把发现的问题记成清单，逐条修正转换规则，再扩大样本量重跑。这个循环走两三遍，比全量导入后回头排查省力得多。
交付时该留下的材料包括：字段对照表、转换规则说明、异常数据清单和处理记录。字段对照表让后来的人知道每个字段从哪来到哪去；转换规则说明写清楚哪些是自动处理的、哪些是人工确认的；异常数据清单记录每一条无法自动处理的数据及其处置结果。这几份材料看起来琐碎，但下次系统再升级时，它们就是最省时间的起点。
数据梳理从来不是一次性的活。业务在变，字段口径也会变，今天对齐的规则明年可能又需要调整。it数运在数字化项目中通常把字段对照作为前置环节，先把问题说明白，再动手写转换逻辑，这样交付出来的结果才经得起核对。
