旧系统的历史数据怎么安全迁移到新系统？会不会丢或乱？

Question

Accepted Answer

结论：历史数据可以低风险迁移，但不能承诺“绝不会丢或乱”。正确做法是冻结并备份源数据，逐字段定义映射和清洗规则，至少完成一次全量试迁与业务对账，再按停机切换或全量加增量同步上线；只有记录、金额、关联关系和关键业务状态全部通过校验，且回退演练成功，才关闭旧系统。

数据迁移不是复制文件。旧系统中的“客户”“订单”“已完成”可能与新系统含义不同；空值、重复记录、时区、精度、编码、附件路径和已删除数据都会造成表面数量相同、业务结果却错误。迁移计划必须由业务负责人、旧系统管理员、新系统团队和数据责任人共同确认，不能只交给脚本开发者猜字段。

三种切换路线直接对比

“新旧并行”不是默认最安全。如果两套系统同时允许修改同一订单，就会产生双主冲突。并行期必须指定每类数据的唯一写入系统：旧系统只读、新系统主写，或按明确的门店和日期分界；任何双向同步都要定义冲突优先级和失败补偿。

盘点所有数据库、Excel、附件、日志和第三方系统，记录表数量、记录量、数据体积、主键、时间范围、负责人、敏感级别和保留要求。随后形成字段映射：旧字段到新字段的对应关系、类型与长度转换、枚举映射、空值处理、金额精度、时区、去重键、关联顺序和不迁移原因。

不能修复的数据要建立异常清单，而不是静默填默认值。比如历史客户没有手机号，需决定允许空值、人工补录还是只保留历史查询；旧订单状态含义不清，应由业务负责人签字确认。源数据提取过程原则上只读，迁移前备份并验证可恢复，导出文件加密、限制访问、记录校验值和销毁时间。

先在隔离环境全量或按足够代表性的范围试迁，覆盖最早与最新数据、中文及特殊字符、大附件、空值、重复、跨表关系、已退款、已取消和正在进行的业务。记录抽取、转换、导入、索引重建和校验分别耗时，以此计算正式窗口；数据量翻倍时耗时未必线性增长。

校验分四层。结构层检查表、字段、索引和约束；数量层比较源目标记录数、空值数和去重数；内容层按主键做行级或哈希比对；业务层核对订单金额、库存数量、账户余额、课时余额、会员积分和状态分布。金额与余额不能只抽样，应按业务允许范围全量对账；附件需验证可打开、归属正确及校验值一致。

AWS DMS 官方文档也把迁移验证定义为源目标对应行比较，并报告待验证、失败和无法验证记录；这说明“脚本执行成功”不等于数据一致。采用其他工具时也应保留等价报告。

正式切换前再次备份，暂停或明确源系统写入，记录增量水位；导入最后增量后执行同一套自动对账，再由财务、运营或教务完成关键任务冒烟测试。上线条件应写为：关键表失败记录为 0、金额和余额差异为 0、允许忽略项已有负责人批准、增量延迟低于窗口阈值，而不是笼统的“基本一致”。

提前定义回退触发条件，如关键关系缺失、对账差异无法在窗口内解释、核心流程失败或增量同步中断。回退不仅是打开旧系统，还要处理新系统切换后产生的数据，避免二次丢失。旧系统保持只读到业务完成一个完整结算周期并签字确认，再按法定保留和合同要求归档或下线。

滚水科技实施迁移时，会把源快照、映射表、清洗规则、脚本版本、异常清单、对账报告和回退记录作为交付件。是否使用 AWS DMS、数据库原生工具或定制脚本，取决于源目标类型、数据量、停机窗口和预算；工具名称不能代替业务对账。