老旧系统迁移改造技术方案，最稳的路线是数据双写加流量切换：新旧库并行写入保证数据连续，流量按比例逐步切到新系统，全程可回滚。保定很多迁移事故都是图省事一把切流量造成的，下面把这套方案的实操步骤按顺序讲清楚。

第一阶段：数据双写搭建

双写的三种实现方式

应用层双写：在业务代码里同时写新旧两个库，优点是可控、事务边界清晰；缺点是要改代码，老系统代码烂的话改不动。数据库层双写：用触发器或CDC（变更数据捕获）工具把旧库的增量变化同步到新库，不用改应用代码，适合老系统改不动的场景。日志解析双写：解析数据库日志（如binlog）实时同步，性能开销最小，但对运维要求高。

选哪种方式看老系统状态：代码可维护选应用层，代码不可维护选CDC方式。经验是大多数老旧系统走CDC路线，用DataX或自研同步脚本做增量。

双写期间的数据校验

双写不等于数据一致。每天凌晨跑对账任务：对比新旧库当天的记录数、抽样核对关键字段。差异率超过万分之一就要查同步日志，看哪条消息丢了。连续一周差异率为零，才说明双写机制稳定。

对账脚本要留痕。每天的对账结果存表，一周后拉趋势图。差异率忽高忽低说明同步机制不稳，得查根因，不能靠每天重跑碰运气。

双写期间旧库仍是主写入口，新库只做影子同步。这样即便新库出问题，业务也不受影响。

双写期间旧库仍是主写入口，新库只做影子同步。这样即便新库出问题，业务也不受影响。

第二阶段：流量切换实施

切流的技术手段

流量切换按技术层次选方案：网关层切流（在API网关按比例转发）最灵活，适合微服务架构；负载均衡层切流（在Nginx按权重分发）简单直接，适合单体应用；DNS切流（按域名解析分流）适合整套系统整体切换。

切流比例按十、五十、一百的阶梯走：先切百分之十观察三天，再切百分之五十观察三天，最后全量。每一步都准备一键回退开关，标准做法是回退开关放在运维控制台，十分钟内可执行。

读流量和写流量分开切

更稳妥的做法是先切读流量：查询请求先走新系统，写入还在旧库。读流量稳定一周后再切写流量。这样新系统出问题只影响查询，不影响业务数据。反过来先切写流量，一旦新库出问题就是业务事故。

切流过程要有监控看板。实时看新旧系统的请求量、响应时间、错误率，一旦新系统错误率超过阈值，自动触发回滚。保定项目里这套看板和回滚开关提前搭好，切流时心里才有底。

整套方案的精髓是把大风险拆成小步骤：双写保底数据连续，阶梯切流控制爆炸半径，每步都有回退。保定团队执行时关键是不跳步、不图快，按节奏走完迁移就稳了。

第三阶段：切换后验证与下线

验证清单怎么列

全量切换后连续七天做三件事：业务冒烟（核心流程每天跑一遍）、数据对账（每天比对新旧库全量数据）、性能监控（响应时间、错误率对比切换前基线）。七天全部达标，才进入旧系统下线流程。

旧系统怎么安全下线

下线不是直接关服务器。先把旧系统设为只读模式跑两周，确认没有业务再访问；然后做全量数据归档备份，保留三年；最后才关停服务。经验是总有一两个边缘业务还在偷偷连旧系统，只读模式能把这些隐藏依赖暴露出来。

归档数据用低成本存储。旧库数据迁到冷存储，不占生产资源，需要时还能查。

回滚开关要提前演练。切换前在测试环境完整走一遍回滚流程，确认四十五分钟内能切回旧库。预案写得再好，真到执行时脚本报错就尴尬了。

数据双写加流量切换这套方案，把迁移风险拆成了可控的小步骤：每一步都有校验点、每一步都能回滚。老旧系统迁移按这个节奏走，业务中断时间可以控制在分钟级。

切换窗口选在周末凌晨。业务量最小，出问题也有完整工作日处理。选在工作日切换，等于把风险放大十倍。

数据迁移分三轮：全量迁移做一次、增量同步持续跑、切换当天再追平最后一笔。三轮下来数据零丢失。

迁移过程用户培训要提前。老系统点惯的按钮新系统位置变了，用户不熟悉会以为数据丢了。培训和操作手册不能省。

迁移期用户手册更新。新系统操作截图全套做出来，打印贴在工位旁。用户上手快，投诉就少。

迁移不是把数据搬完就结束。新系统跑顺一个月，迁移项目才算收尾。

迁移期用户培训同步做，新系统手册和操作视频提前准备好。

保定团队执行时关键是把每个校验点的记录留全，出问题时能快速定位是哪一步出了偏差。