迁移数据这件事，听起来像是把一堆文件从抽屉搬到新柜子。其实，真把它搬进真实场景里，就会发现它远比搬家具复杂。记得我第一次帮朋友把老旧的本地 CRM 系统迁到云端，文件夹里全是 Excel、PDF、历史邮件，老板还在旁边喊“别弄丢了”。我把整个过程比作一次“数据搬家”，从打包、清点、装车到搬进新家，每一步都得小心翼翼。搬家前要先把东西分类，哪些是必需品，哪些是旧的、可以扔掉；搬家时要防止碰撞、压坏；进新家后还得重新摆放、连线、调试。数据迁移同理，只是把“东西”换成了结构化表、半结构化日志、二进制对象，搬运工具从手推车变成了 ETL 工具、API、数据管道。把这段经历摆在桌面上，你会发现大多数企业在迁移前根本没有做好清点和分类，导致迁移后出现数据缺失、字段错位，甚至业务报错。于是，搬家前的盘点、标签、清理，成了迁移成功的第一道门槛。
盘点的细节往往被忽视。很多公司把所有数据库当成一个整体，直接用全量导出工具一次性搬过去。结果，旧系统里混杂着历史无效数据、测试数据，甚至开发者随手写的临时表。一次我在客户的 ERP 系统里发现一张叫 “temp_20211231” 的表，里面全是测试订单，迁过去后导致财务报表多出一笔巨额“虚假”收入。要避免这种尴尬，先得用 SQL 脚本或数据质量工具把数据按业务线、时间段、状态标签分类。比如，把 “已完成、已结算、已归档” 的订单标记为正式数据，其他的标记为清理对象。再配合数据剖析工具，快速生成数据分布报告，看看哪些字段出现异常值、哪些表的行数异常增长。这样在迁移前就能把“垃圾”挑出来，防止它们进了新系统后把整个业务链条搞得一团糟。盘点的过程其实也是一次业务审计，往往能帮企业发现多年未解的业务漏洞。
清理环节比盘点更像是给数据做一次体检。体检报告出来后，你会看到血压偏高、血糖偏低的指标，需要对应的调理方案。数据清理同样要分层处理：先去重，后标准化，最后补全。去重看似简单，实际常常因为主键定义不统一而失效。一次我帮一家电商平台把客户表迁到新 CRM 时，发现同一个客户有三条记录，分别用手机号码、邮箱、会员卡号做主键。直接去重会把有效信息删掉，于是我们先把所有唯一标识统一成一个 “全局客户 ID”，再基于业务规则合并字段。标准化涉及时间格式、地址编码、货币单位等。老系统里有的日期是 “YY/MM/DD”，有的是 “DD-MM-YY”，还有的直接是 Excel 序号。我们用了 Python 脚本统一成 ISO 8601 格式，并把时区统一为 UTC。补全最头疼，因为缺失的数据往往出现在关键业务节点。我们通过关联外部系统的日志、订单流水，逆向填补了缺失的地址信息，确保迁移后用户画像完整。清理完的“干净”数据，就像洗完澡的孩子，舒服得可以直接进新家。
搬运工具的选择决定了迁移的速度和安全性。市面上从开源的 Sqoop、Airflow，到商业的 Informatica、Talend，各有千秋。关键是看业务对实时性、容错性、转化需求的要求。一次金融机构要把每日交易日志从本地 Hadoop 迁到云上的 Snowflake，要求延迟不超过 5 分钟，还要保证每条记录的完整性。我们用 Kafka 做实时采集，配合 Flink 做流式转换，写入 Snowflake 的分区表。整个链路设计成 “先写本地缓存，再异步落库”，即使云端出现短暂网络抖动，也不会丢数据。相反，某制造企业只需要每月一次的批量迁移，直接用 Sqoop 全量导出、压缩、SCP 传输即可，省去多余的实时组件。工具选型还要考虑团队熟悉度和运维成本，别为了追新技术把自己套进一堆没人会维护的脚本里。选对工具后，记得写好监控和告警，迁移过程中一旦出现数据漏写、异常延迟，能够快速定位并回滚。
回滚策略往往是迁移计划里最被低估的章节。搬家时，很多人只想 “搬完就好”，却忽略了搬家途中可能摔坏的家具。数据迁移同理，如果新系统上线后发现关键报表不对，或者用户登录异常，必须有快速回滚的办法。常用的方式是先在目标环境做一个只读副本，等所有验证通过后再切换写权限。这样即使出现问题，也能在几分钟内把流量切回老系统。还有一种更保险的做法是“双写”，即在迁移期间，业务同时写入老库和新库，等新库验证完整后再停掉老库的写入口。一次我参与的保险公司项目，采用双写方式后，业务团队在新系统上线后两周内没有出现任何业务中断，因为所有关键交易都有老系统的备份。回滚计划一定要演练，最好在非生产环境跑一次全流程，确认脚本、权限、网络都能配合。只有这样，迁移才不会变成一次 “惊险的搬家”。
迁移完成后，还要进行 “入住检查”。这一步类似于搬进新家后检查水电、门窗是否正常。数据层面主要是校验数据量、校验关键业务指标、做端到端的功能测试。最直接的方式是跑一遍老系统的报表，和新系统的同名报表进行对比，差异超过阈值时立刻追踪根因。还有一种更细致的做法是抽样检查：随机抽取几千条记录，逐条比对字段值、关联关系、时间戳等。对比结果如果在可接受范围内，就可以放心把业务切换到新系统。除此之外，还要检查数据安全和合规性，例如加密字段是否保持原有的加密方式，访问控制是否仍然符合 GDPR 或国内的个人信息保护法。一次医疗健康平台在迁移后被审计发现，患者的身份证号在新库里被明文存储，导致合规风险。若在入住检查阶段就发现这个问题，完全可以在上线前修正加密逻辑，避免后续的法律纠纷。入住检查其实是对整个迁移过程的一次 “体检”，只有通过后，才能真正把新系统交给业务使用。
从整体来看，数据迁移并不是一次技术任务，而是一次跨部门、跨系统的协同演练。它把业务审计、数据治理、技术实现、运维监控、合规检查全部串在一起。把迁移当成一次搬家，可以帮助团队从 “搬东西” 转向 “搬生活”。做好盘点、清理、工具选型、回滚和入住检查，每一步都要具体到表、到字段、到业务场景，而不是停留在宏观的 “迁移计划”。只有把这些细节落到实处，企业才能在换平台、换技术栈的过程中不丢业务、不丢客户，也不丢掉对数据的信任。数据迁移不只是技术，更是一种对业务负责的态度。
