旧系统数据迁移最容易翻车在哪？上线前要做校验、切换和回滚

企业更换ERP、CRM、商城或自研业务系统时，开发完成往往只完成了一半。真正危险的阶段是把旧系统多年积累的数据迁入新系统，并在某个时间点完成正式切换。

第一步不是导数据，而是盘点数据

需要先知道旧系统里到底有什么：客户、商品、订单、库存、合同、财务记录、附件、账号和历史日志分别存在哪里。

同一个“客户手机号”在不同表里可能格式不同，同一个商品可能存在重复编码。没有数据盘点就直接写迁移脚本，问题只会被带到新系统。

建立字段映射表

旧字段和新字段通常不是一一对应。

要明确字段名称、类型、是否必填、默认值、枚举转换、主外键关系以及历史状态如何映射。

字段映射表最好由业务人员和技术人员共同确认，因为技术团队知道数据库，但业务团队才知道“待审核”“已完成”这些状态真正代表什么。

先清洗，再迁移

重复客户、无效手机号、历史测试订单、错误库存和孤立附件都可能存在多年。

迁移脚本不应该默默猜答案。无法自动判断的数据应该形成异常清单，让业务负责人决定保留、修复还是舍弃。

必须做迁移后的数据校验

不能因为脚本执行没有报错，就认为迁移成功。

至少应比较关键表的总记录数、金额汇总、库存总量、状态分布和随机样本；高价值业务还可以对源库和目标库做逐行或主键级校验。

AWS DMS官方最佳实践也把Source与Target的数据验证作为迁移准确性的重要步骤。

正式上线前要演练Cutover

最好至少做一次完整预演：从备份、全量导入、增量同步、停止旧系统写入、最终同步，到切换应用连接。

这样才能真实测出迁移需要多久，并确定企业能够接受多长停机窗口。

新旧系统同时发生写入怎么办

如果迁移期间旧系统还在新增订单，单纯复制一次数据库一定会漏数据。

可以通过增量同步、CDC或明确停写窗口解决，但具体方法取决于系统架构。最危险的是没有方案，却假设“上线当天再导一次就行”。

回滚必须在上线前设计

回滚不能等事故发生才讨论。

需要明确什么条件触发回滚、谁有权决定、DNS或应用连接怎么切回、旧数据库在切换后是否还保持可恢复，以及新系统已经产生的数据怎样处理。

AWS关于Migration Cutover的指导也强调预先定义回滚检查点和数据处理策略。

迁移完成后不要马上删旧库

旧系统应在约定观察期内保持只读备份，并明确最终归档和销毁规则。

涉及个人信息、财务或敏感数据时，还要考虑访问权限与企业自身的数据保存要求。

资料依据

AWS Database Migration Service官方《Best practices for AWS DMS》关于数据验证、迁移监测和源目标比对的指导。

AWS Prescriptive Guidance《Cutover stage》关于切换条件、Rollback和切换后新增数据处理的建议。

结论

数据迁移真正的交付物不只是一个成功执行的脚本，而是一套可解释、可校验、可演练、可回滚的上线过程。