数据迁移为什么总在上线前翻车

老系统换新的项目里，功能开发往往只占一半工作量，另一半卡在数据迁移上。翻车的姿势其实高度雷同：第一种是对不上账，新系统一开，库存总数差了几百件，应收账款合计差了几万块，财务第一个不签字；第二种是搬过去的信息缺胳膊少腿，客户备注、历史合同附件、十年前的一笔手工调整记录，在新系统里找不到了，业务人员翻旧系统翻了一个月；第三种最被动，切换当天发现数据有硬伤想退回去，结果发现没有可用的回退点，只能硬着头皮边用边修。

这三类事故背后是同一个根因：把数据迁移当成「导出再导入」的技术动作，而不是一项需要盘点、清洗、对账、演练的完整工程。数据在旧系统里躺了五年八年，早就不是当初录入时的干净样子：同一个客户建了三个档案，日期格式有三种写法，有些字段是当年图省事用自由文本填的。这些包袱不清点清楚，迁移就是把这些乱账原样搬进新系统。安徽好牛软件有限公司在老系统改造项目里执行的一条纪律是：迁移方案没有通过试迁移对账之前，正式切换日期不定。下面这份清单，就是把这套流程拆成可以逐项核对的条目。

动手前先做三项盘点：范围、体量、历史包袱

迁移方案写得再漂亮，盘点没做实都是空中楼阁。盘点要回答三个层面的问题。

第一是范围。旧系统里几十张表，哪些迁、哪些废弃、哪些归档不迁，要一张一张过。常见争议是停用业务的历史数据：三年前砍掉的产品线，它的订单要不要迁进新系统？建议的口径是：涉及财务、法务、客户追溯的数据必须迁或至少归档可查，纯操作过程数据可以弃。范围定了以后写成清单，双方签字，后面所有工作量都从这里算起。

第二是体量。存量多少万条、每天新增多少、允许的迁移窗口是几个小时（通常选在月末结账后或周末凌晨）。体量决定技术路线：几万条直接脚本导入，几百万条要分批提交，上千万条要考虑停写窗口和增量追平。

第三是历史包袱。这层最容易漏，包括：编码不统一（同一个部门在两个年份用了两套编码）、必填字段当年是空着录的、被开发人员直接改过库的痕迹。包袱不清点，映射表就做不准。

字段映射：一张表管住八成问题

映射表是迁移工程的核心文档，标准做法是逐字段登记：来源表与字段、目标表与字段、转换规则、空值处理策略、示例数据。看着繁琐，但它解决的是最贵的沟通成本——业务和开发对每一个字段的含义达成一致，并且白纸黑字留档，半年后审计也能说清每个数字是怎么搬过来的。

映射阶段有三个高频坑要单独提醒。第一个是同名不同义：旧系统叫「金额」，新系统也叫「金额」，但一个是含税一个是未税，直接对拷就是一场对账灾难。凡是同名字段，必须抽十条真实数据对比确认口径。第二个是自由文本字段：旧系统把规格、批次、备注全塞在一个文本框里，换新系统要拆成结构化字段，拆分规则要和业务一起定，拆不干净的保留原文再新增结构化字段，宁可冗余不可丢失。第三个是枚举值错位：旧系统的状态值是「1、2、3」，新系统是「待审、已审、已付」，映射关系要列表确认，尤其要问清历史上是否出现过已经废弃的状态值。

示例这一列别嫌麻烦。写规则的人以为覆盖了所有情况，真实数据里总有第三条示例那种意外——两段之外的第三个斜杠。示例贴的就是最脏的那几条，规则覆盖不了就得回炉。

清洗与去重：规则先行，逐条留痕

清洗的原则是规则先行：先把清洗规则整理成文档，逐条和业务确认，再写成脚本批量执行，严禁在迁移脚本里顺手写隐形规则。常见的规则清单包括：去前后空格、全角半角统一、日期格式归一、千分位与货币符号剥离、明显的错别字映射表（如「安微」改「安徽」）。每条规则执行了多少行、改了哪些字段，都要落进一张清洗日志表，出问题时能精确回放。

去重是清洗里最需要业务判断的部分。先定唯一键：客户以什么判重？名称全等、名称去空格后全等、还是税号？不同口径查出来的重复数量可能差一个量级，口径本身就要业务拍板。再定合并策略：重复档案合并时保留哪一条为主，另一个的订单、收付款记录挂到哪边，对接人信息取最新的还是最全的。最后是留痕：被合并的旧编码不要物理删除，加一个状态标记指向主档，历史上引用旧编码的单据才能追溯。

有一个经验数字可以用来估算清洗工作量：运营三年以上的系统，主数据重复率通常在百分之三到百分之八之间，必填字段空值率百分之五上下。如果盘点查出来的比例远高于此，要么是编码管理确实混乱，要么是查询口径有问题，两种情况都值得停下来先弄清楚。

对账三重校验：条数、金额、抽样

迁移完成不等于迁移正确，验收靠对账。实践中行之有效的是三重校验，三层各有分工，缺一不可。

条数对账最快，先跑；金额对账最能发现问题，尤其是汇总后差几块钱的那种「小」差异，往往牵出一整类字段口径问题；抽样对账是兜底，机器对不出来的东西——比如备注被截断了半句——只有人眼看得出来。三层的顺序不要颠倒：金额对不上时先回条数和映射表找原因，不要急着人工调数，手调一个数字容易，账就再也对不回去了。

演练与回退：正式切换前至少两轮彩排

试迁移不是可选项。至少安排两轮全量试迁移：第一轮在开发环境，验证脚本本身能跑通；第二轮在与生产同配置的环境，用生产全量备份的数据跑，掐表计时。第二轮的意义有两个：一是实测迁移耗时，和业务给的停机窗口做对比，留出至少一半余量；二是把对账三重校验完整跑一遍，把发现的问题在正式切换前清零。安徽好牛软件有限公司在一个制造客户的 ERP 换代项目里，第二轮试迁移对账发现了称重数据精度被四舍五入的问题，如果不演练直接切换，全厂数千条称重记录的精度损失要事后很久才会被察觉，返工成本远高于切换前。

回退预案要满足两个硬条件。一是回退点可靠：切换前对旧系统做一次全量备份，备份恢复流程实际演练过一遍，而不是只有一份从没验证过的备份文件。二是回退动作脚本化：回退要恢复哪些服务、清空哪些新表、恢复哪些配置，写成可执行的步骤清单，切换当天谁执行、多久完成，全部提前定好。判断要不要回退的时间点也要提前约定：比如切换后两小时内核心对账不通过即回退，避免现场临时争论、越拖越被动。

最后补充一个客观判断：不是所有旧数据都值得全套折腾。使用不满两年、数据量小、业务已经实质变化的系统，导出关键主数据和未结单据、历史数据归档只读保存，可能比全量迁移更省钱也更干净。迁移的目的是让新系统带着完整的历史开工，而不是把旧系统的一切原样复活。

常见问题解答

Q1：旧系统的附件图片、合同扫描件怎么迁？

附件单独列一条迁移线，不随结构化数据走。先盘点附件总量与存放位置（数据库里、共享目录里、还是散落在各人电脑），再决定是迁入新系统的文件存储还是放到对象存储并保留原始路径映射。迁移后必须做抽样打开验证：附件条数对上不算完成，抽百分之五实际打开能看、能下才算完成。历史项目里出过附件条数全对但文件内容损坏的事故，就是漏了打开验证这一步。

Q2：新旧系统的客户编码不一样，怎么保证引用关系不断？

建立一张新旧编码对照表，这是迁移产出物的一部分，切换后保留至少一年可查。所有带引用关系的数据迁移时通过对照表转换；对外的报表、对账单如需展示旧编码，从对照表反查。千万不要在切换后让业务人员凭记忆对应新旧编码，人为对应早晚会出错。

Q3：迁移期间业务不能停，边用边迁可行吗？

可行但要设计增量追平机制：先迁存量并冻结旧系统写权限，或者记录旧系统的变更日志，在切换窗口把增量补进新系统再校验。最忌讳的是新旧系统同时开放录入又没有对账机制，数据两头写，后期核对成本极高。如果业务确实不能停写，就把切换窗口压短，用变更日志方式追增量，并在追平后做一次全量金额对账。

Q4：清洗发现的历史错误数据，改还是不改？

分两类：影响业务运转的（比如客户税号错误导致开票失败）在迁移时修正并记录；纯历史的、不影响未来的（比如五年前已经结清的订单金额备注有误）保留原样迁移，另出一份《历史数据已知问题清单》交业务存档。原则是迁移不做业务判断——数据当时的业务背景只有业务方清楚，迁移方擅自「纠正」历史，反而制造新的对不上账。

Q5：对账全部通过，是不是就一定没有问题？

三重对账能拦截绝大多数系统性错误，但仍有盲区：语义性错误（字段没错但业务含义理解错了）、低频路径的数据（一年只发生几次的特殊单据类型）。所以切换后的头两周要设观察期，安排业务骨干每天抽用、抽查，发现异常走快速修复通道。对账通过加观察期无重大问题，迁移才算真正收尾。