老系统换新系统，数据怎么搬？三种迁移切换方案对比

企业换系统最提心吊胆的环节不是开发，是切换：老系统里的几百万条业务数据、十几年积累的单据档案，怎么搬到新系统里？搬丢了、搬错了、切换当天业务停摆，任何一个闪失都是事故。更现实的问题是——切换期间业务不能停，仓库还要发货，财务还要记账。

核心矛盾是：迁移要追平不停产生的增量数据，而切换窗口越短风险越集中，选哪条路线，决定了停机时长、数据一致性保障和回退能力的平衡点在哪。 业界有三条主流路线：停机一次性迁移、双写并行过渡、CDC 实时同步渐进切换，停机成本和技术复杂度逐级变化。

方案一：停机一次性迁移

原理： 选业务低峰（周末或月末结账后），老系统停机禁止写入，全量数据导出、清洗、转换、导入新系统，校验通过后新系统直接接管。一次切换，一步到位。

优点：

• 架构最简单：不需要中间件，一次性脚本工程，开发量最小
• 数据一致性天然有保障：停机后老系统不再有增量，迁完就是终态
• 成本最低：不用维护双轨运行，周期短则一个周末

缺点：

• 停机窗口硬约束：数据量一大，导出导入加校验可能超过业务能承受的停机时长
• 风险高度集中：切换成功就是成功，失败就得回退重来，一次定生死
• 回退代价大：新系统跑出问题想回退，老系统已经落后了新数据，回退也要迁移

适用场景： 数据量百万级以内、业务有明显低峰期、允许停机数小时到一天的中小企业系统。进销存、OA 这类非 7x24 系统的主力方案。

方案二：双写并行过渡

原理： 迁移期内业务双轨运行：新老系统同时可用，关键业务两边各做一遍（或应用层双写），持续对账确认数据一致，观察期结束后老系统下线。历史数据提前批量搬迁，增量靠双写保证。

优点：

• 风险最可控：新系统出问题随时切回老系统，业务感知最小
• 验证最充分：双轨运行期就是真实业务的验收测试，数据差异每天对账
• 停机窗口趋近于零：切换只是"老系统不再使用"的一个决定

缺点：

• 成本最高：双轨运行期间业务操作量翻倍（人工双录）或开发量翻倍（应用双写）
• 周期拖得长：观察期动辄一到三个月，项目周期被显著拉长
• 双写一致性是个坑：一边成功一边失败的处理、双写顺序问题，应用层实现远没有听起来简单

适用场景： 财务、核心交易等"错不起"的系统，或组织架构复杂、需要分批切换分支机构的大型企业。

方案三：CDC 实时同步渐进切换

原理： 通过 CDC（Change Data Capture，如 Debezium、Canal、云数据库 DTS）捕获老数据库的 binlog/WAL 变更，实时同步到新库；历史数据先全量迁移，增量由 CDC 追平；新系统并行验证充分后，找个低峰点停写几分钟完成最终追平，切流量到新系统。

优点：

• 停机窗口极短：最终切换只需分钟级停写，适合 7x24 业务
• 业务零双写：老系统照常运行，业务侧完全无感知
• 可灰度：支持按模块、按租户分批切换，风险摊薄到每一小步

缺点：

• 技术门槛最高：CDC 链路、数据转换、延迟监控、断点续传，需要专业数据工程能力
• 新老库结构差异大时转换复杂：不是简单的表对表，映射规则要精心设计
• 同步链路要兜底：CDC 中断、数据堆积、追不平，每个异常都要有预案

适用场景： 电商交易、物流调度等不允许停机的核心业务系统，或数据量千万级以上、全量迁移耗时不可接受的场景。

按停机容忍度对号入座

实战中的组合策略是分级对待：外围系统（OA、报表）直接停机迁移，简单省钱；核心系统（订单、财务）走 CDC 或双写，把风险预算花在刀刃上。

落地前必做的三件事

第一件：数据盘点先于方案选型。 要迁哪些表、历史数据保留几年、脏数据怎么清洗、编码规则新老怎么映射，盘清楚才知道迁移工作量。很多项目延期不是切换技术难，是数据质量烂。

第二件：对账方案要在迁移前写好。 迁完怎么证明"一条不多一条不少"？总量校验、抽样比对、关键业务余额核对三级对账方案，作为迁移验收的硬性标准，而不是迁移后补做。

第三件：回退预案要真实演练。 切换失败后多少分钟内回退、回退后增量数据怎么处理、谁有权拍板回退，写成预案并真演一遍。没演练过的回退预案，约等于没有预案。

写在最后

系统切换的核心不是"怎么搬数据"，而是"停机窗口和数据一致性愿意付出什么代价"。三条路线没有高下，只有匹配。先把数据家底盘清楚、对账标准定死、回退预案演练过，再谈切换日期——切换成功的项目，功夫全在切换日之前。