迁移前的评估会上，业务方说系统不复杂，几张表而已。技术负责人打开数据库一看，表有两百多张，字段命名混杂着拼音缩写和英文简写，还有几个字段谁也说不清用途。会议开了两个小时，最后卡在一个问题上：这些数据里，哪些是必须带走的，哪些可以留在原地。迁移项目失败，很少是代码写不出来，更多是清点没做全，搬到一半才发现漏了东西。
第一类要清点的是数据本身。逐表记录表名、用途、数据量、更新频率，重点看字段含义。历史遗留字段最容易出问题，比如一个叫flag的字段，可能同时承担删除标记和审核状态两种含义。空值和默认值也要单独标注，某字段为空时业务上代表未填写还是代表不适用，迁移规则完全不同。这一步的产出是一张字段说明表，每个字段后面写清楚含义、类型、是否必填、空值含义。
第二类要清点数据之间的关系。主外键是最基础的，但真正麻烦的是没有建外键却靠程序维护的关联。冗余字段也要留意，同一个客户名称可能同时存在客户表和订单表里，迁移时以哪边为准需要提前定。跨系统引用更隐蔽，旧系统的订单号可能被另一个系统当作索引使用，这类外部依赖必须逐个问出来。
第三类要清点使用数据的人。谁在查、谁在改、谁在导出，分别用到哪些字段。报表是最容易漏的环节，一张月度统计表可能依赖五个字段的组合逻辑，迁移时少一个，报表数字就对不上。建议把主要报表列出来，逐张标注数据来源字段，再找报表使用人确认口径。
第四类要清点迁移后必须保留的历史。审计记录、附件文件、操作日志、版本信息，这些内容往往不在主表里，却经常被业务或合规要求保留。附件要确认存储位置和文件数量，日志要确认保留期限，版本信息要确认是否需要随主数据一起迁移。
清点完成后，把以上四类内容整理成一份清单，每项后面留三列：现状说明、迁移处理方式、业务方确认。确认环节不能只发邮件，要拉着业务方逐项过，尤其是字段含义和报表依赖，口头确认后当场记录。清单上有争议的项先标出来，不带着疑问进入开发。
清点做在前面，成本是开会和填表；迁移后才发现漏数据，成本是回滚、补录和重新对账。it数运在需求梳理阶段通常先做这一步，把数据盘清楚再谈方案，后面的事情会顺很多。
