新系统开发得再好，数据搬不过去或者搬错了，业务就接不上。数据迁移往往排在整个项目计划的末尾，时间被前面的环节挤压，最后匆匆做一遍就上线，问题在上线后一个月内陆续冒出来。
把迁移当成一个独立的小项目来排，给它留够时间，是避免这类问题的前提。
一、迁移前先做三件事
第一件是盘点。列出旧系统里到底有哪些数据、各有多少条、哪些是在用的哪些是历史沉淀。盘点的时候要区分核心数据和附属数据。核心数据是业务离不开的，比如客户档案、合同、在办的业务单据。附属数据是查得到更好、查不到也能过的，比如多年前的沟通记录、附件文件。
第二件是清洗。旧系统跑久了，数据一定脏。同一个人可能有三个档案，手机号格式不统一，必填项有一堆空值，已经注销的客户和活跃客户混在一起。迁移之前要定规则，哪些合并、哪些补全、哪些直接放弃。清洗规则要写下来，因为同样的判断后面还会用到。
第三件是映射。旧系统的字段和新系统的字段不是一对一。旧系统一个备注字段里混着多种信息，新系统分成了五个字段，怎么拆。旧系统的一个状态值，新系统没有对应项，归到哪一类。这些都要形成对照表，一条条确认。
二、迁移过程必须能回退
迁移之前要把旧系统的数据完整备份，而且这份备份要能独立还原。这句话看着像废话，但确实有项目在迁移失败后才发现备份是增量备份，还原不出完整的旧系统。
正式迁移建议分两次做。第一次是演练，把数据搬到测试环境，跑一遍完整流程，记录耗时和遇到的问题。第二次才是正式迁移，安排在业务空闲时段，比如周末或者夜间。
迁移当天要留够时间窗口。按演练的耗时乘以一点五来安排，留出处理意外的余地。如果时间到了还没做完，要有明确的决策点，是继续做完还是回退到旧系统明天再说。这个决策点让谁拍板，提前定好。
三、迁移完怎么核对
核对不能只看总数对不对。总数一致但内容错位的情况很常见。
建议做三层核对。第一层数量核对，每张表迁移前后的条数要一致，不一致的说明差在哪。第二层抽样核对，每个业务模块随机抽二十条，逐字段比对内容和格式，重点看日期、金额、状态这些容易出错的字段。第三层业务核对，让每个业务岗位自己去看几笔熟悉的单据，看是不是和原来一致。第三层最费时间但最有价值，业务人员熟悉自己的数据，一眼能看出不对。
核对结果要留记录，谁核的、核了多少条、发现什么问题、怎么处理的。这份记录在上线后出问题时，是判断责任和快速定位的依据。
四、有些数据可以不用迁
把所有历史数据都搬过去，是一种常见的冲动，但未必划算。年代久远的流水数据，如果新系统里没有对应的查询需求，搬过去只是占空间，还会拖慢迁移进度。
比较务实的做法是分层。近一到三年的业务数据必须迁，这是日常要用到的。更早的数据可以只迁关键索引信息，比如单据编号、金额、日期，明细留在旧系统里备查，或者导出成文件归档。附件类数据单独评估，大文件往往占迁移时间的绝大部分，如果新系统不需要在线查看，可以只保留索引。
这个取舍要跟业务方一起定，不能由技术方单方面决定。哪些数据以后会查、哪些基本不会再看，只有业务人员说得清楚。