换系统的时候，数据为什么搬不动？

公司决定换一套业务系统，负责人原本估的是一周：旧系统有导出功能，新系统有导入模板，两步的事。实际情况是项目拖了一个多月。导出的表格打开一看，字段名和新系统对不上；客户状态这一栏，有的写“已成交”，有的写“成交”，还有的写“已签”；几百份合同附件导出来之后，找不到该挂回哪个客户下面；两个部门的客户合并到一起，重复的记录一大片。导出没报错，导入也显示成功，可数据进来之后就是不能用。

先把结论放在前面：数据搬不动，多数不是工具的问题，而是这些数据从录进旧系统那天起，就没被当作“将来要搬走的数据”来管。迁移这一步，是把平时积累下来的所有含糊，一次性摊开在桌面上。

数据卡住的四个根因

把失败案例拆开看，卡点反复出现在四个地方。

四个根因有同一个特点：在旧系统里天天用的时候，都不算问题。字段含义靠习惯补齐，写法靠记忆对齐，关联靠点开详情页就能看到，数据质量差一点也忍了。旧系统在替人兜底，换系统的时候，兜底的人换成了没有记忆的新系统。

为什么平时感觉不到

这不是哪个团队特别粗心，而是数据问题天然是“延迟暴露”的。录入时省的那两分钟，当场没有任何代价；写法各写各的，当天也看不出影响。代价出现在另一个时间点——要按字段筛选的时候、要出报表的时候、要换系统的时候。距离当初的录入越远，修起来的成本越高，因为当时知道含义的人可能已经不在了。

所以迁移项目的排期常常失准。负责人按“导出加导入”估时间，实际工作量花在翻译上：把习惯翻译成定义，把各种写法翻译成统一口径，把散落的表格重新挂回关系上。这部分工作量平时不显现，一搬家全冒出来。

搬之前先做三件事

第一件，盘字段清单。把旧系统里每个字段列出来，逐个回答三个问题：这个字段存的是什么、现在谁在用、新系统里放到哪里。答不上来的字段，多半就是平时没人用的，趁迁移决定去留，别把含义不明的数据原样搬进新家。

第二件，先统一写法再清洗。客户状态、来源、地区这类字段，先在纸面上定好统一的取值，再照着清单把旧数据归一遍类。这一步在导出之前做，比导出之后在新系统里修省力得多——表格里改一百行，比在上线后的系统里改一千条记录容易。

第三件，小批试搬。先挑一个部门的客户，把字段、关联、附件整个流程走一遍，确认搬进来的数据在新系统里筛得动、查得对、挂得上，再扩大范围。全量搬迁一上来就做，错了返工的代价最大。

双轨期怎么安排

新旧系统并行的那段时间，最容易出现两头都记、两头都不全。规矩要在切换前就定死：以哪一边为准录入，另一边只读不写；切换日是哪天，切换之后再发现旧数据有问题，走什么流程修正。没定规矩的双轨期，会变成两个系统各长出一套新数据，回头合并的难度比当初迁移还大。

人员的安排也要跟上。试搬阶段的结论——字段对照表、写法清单、常见问题的处理口径——整理成文档发给所有要录数据的人，别让它只留在项目组几个人的脑子里。

附件与历史记录，最容易丢的部分

客户名单、联系人这些主干数据通常都会搬，先被放弃的往往是附件和历史记录：跟单过程、回访记录、合同扫描件。放弃的理由听起来都合理——量大、难对应、以后未必查。可一旦客户出现争议，要翻“当时说好的是什么”，翻不到，损失就是实打实的。

两条路都行：要么带着搬，把附件挂回对应记录；要么明确归档，旧系统或者存档服务器保留只读访问，写清楚保存期限和查询路径。最糟的是第三种状态——没人决定丢不丢，数据躺在旧系统里慢慢没人会查。

迁移也是一次体检

换个角度看，迁移是数据难得的一次全面盘点。平时不敢删的记录、不好意思合并的重复客户、含义早就没人说得清的字段，趁着搬家做一次取舍。搬完之后的新系统如果比旧系统干净、清楚，这次迁移就不只是换了个工具，而是把数据资产理了一遍；如果原样照搬，等于把旧问题装修进了新房子，用不了多久还会再遇到一次。

常见问题

问：附件和历史记录一定要搬吗？
答：看后续有没有查询需求。涉及约定、承诺、争议可能的记录建议带着走或者明确归档；纯粹过程性的旧数据可以归档不搬家，但要有路径可查。

问：迁移一般要多久？
答：取决于字段数量、数据量和历史质量，很难按“导出加导入”估。先试搬一个小部门，把翻译和清洗的工作量摸出来，再估全量周期，误差会小很多。

问：旧系统停用后，历史数据怎么处理？
答：至少保留一份可查询的归档，明确保存期限、查询入口和负责人。完全依赖某位员工个人电脑里的备份，是最容易出事的做法。

数据搬家难，难在平时。字段有定义、写法有口径、关联挂得住、记录有人管，这些基本功做在日常，换系统就只是一次搬运；做不在日常，迁移就会被迫变成一次重构。哪个时间点开始都不晚，晚的是等到要搬家那天才想起这些事。