旧系统替换是周期长、返工成本高的工作。最容易踩的坑是只关注“功能重做”，忽略了数据口径、权限模型和后台任务这些看不见的依赖。以下是从实际迁移项目里沉淀下来的做法。
先盘点边界
迁移前先列出新系统需要承接的模块，以及旧系统里仍然在运行的接口、数据表、定时任务和外部对接。只有把这些依赖找全，才能判断一次切换能不能完成。
盘点结果需要明确三件事：
- 哪些模块必须迁，哪些可以下线。
- 哪些数据要带过去，哪些历史数据只保留查询。
- 哪些外部系统要在切换窗口内一起联调。
数据迁移
数据迁移不能只跑一次脚本。旧系统数据常常存在字段含义不一致、重复记录、编码混乱等问题，直接搬过去会让新系统上线当天就出问题。
推荐的顺序是清洗、映射、全量迁移、增量迁移、校验。迁移任务需要可重跑，所以每条数据都要有幂等标识，重复执行不会产生重复记录。
校验不是看“数量对不对”就结束，还需要按业务口径抽样核对，例如主表与明细表、订单与支付、用户与权限之间的关系。
功能迁移
功能迁移建议按模块灰度，不要等到全部完成才上线。新系统先承接一部分模块，旧系统继续处理其余模块，两套系统在一段时间内并存。
并存期间需要明确边界：
- 写操作落到哪里，读操作从哪里读。
- 两套系统共用的数据怎么同步。
- 灰度开关如何配置，出现问题时如何快速回退。
切换与回滚
正式切换前要有一个明确的切换窗口：停写、同步最后一批增量、校验、放量。切换窗口里最怕临时发现数据不一致，因此最终校验脚本要提前准备好，并且可重复执行。
回滚预案也要提前写清楚。代码回滚容易，数据回滚很难。通常的做法是保留旧系统为只读状态，新系统出现严重问题时，先恢复读路径，再逐步恢复写路径。
踩坑记录
- 历史数据里的“状态”含义和现在不一样，需要先统一枚举。
- 旧权限模型通常是用户直接挂在多个角色上，新模型需要做映射表。
- 隐藏的定时任务会在切换后继续写旧库，迁移时要把它们全部停掉或改指向。
旧系统迁移最稳妥的节奏不是“一次替换”，而是先让新系统能完整承接，再让旧系统逐步退场。所有切换步骤都要可验证、可回滚，迁移才算真正结束。