老系统升级不必推倒重来：如何设计渐进式替换

01 老系统真正难替换的，是沉淀其中的业务规则

一个年代久远的系统可能仍承担关键业务。代码之外还存在人工补录、特例处理、外部接口与多年形成的操作习惯。只根据页面重新实现功能，容易漏掉让系统真正能运行的隐含规则。

改造前应盘点业务能力、使用者、数据、接口、定时任务与依赖关系，并询问一线人员哪些步骤“必须这样做”。这些答案往往比技术栈清单更能提示迁移风险。

并非所有模块都值得重写。保留稳定且满足需求的能力，封装仍有价值但连接困难的能力，替换变化频繁或限制明显的能力。优先级应由业务价值、依赖和风险共同决定。

可以从客户查询、通知、内容管理或特定订单流程切入，但边界应能够说明输入、输出和数据归属。拆出一个技术服务却仍要求大量跨库写入，可能只是把耦合移到网络上。

渐进式替换的核心是让新旧能力阶段性共存，再逐步转移责任。Martin Fowler 对 Strangler Fig 方法的讨论强调这是一种逐步现代化方式，并不意味着过程会自动变简单。

同一条业务数据如果同时由新旧系统任意修改，很容易产生冲突。每个阶段明确权威来源、同步方向、允许延迟及失败处理，避免为了方便接入而长期双向自由写入。

数据迁移需要核对字段含义、编码映射和历史异常。先试迁移并核验抽样业务，再评估增量同步和正式切换。

挑选真实类型且已脱敏的业务样本，对照新旧系统的关键结果。重点检查金额、状态、权限、导出和外部接口，并记录有意改变的业务规则。

新系统无需复制每个历史缺陷，但对差异要有清楚决定。团队应能解释哪些是修正、哪些是遗漏，以及谁确认了预期行为。

代码可以回退，但新系统已经产生的数据、发出的通知和完成的外部动作未必能撤销。上线方案应说明数据回流、任务停启、入口切换和人工核对。

每个阶段交付一段可以使用的业务能力，并提供培训、运行观察与反馈入口。系统从技术上成功切流，并不代表使用者已经能顺畅完成任务。

监测应同时包括服务错误、接口延迟和业务异常。例如接口成功率正常，但订单积压增长，仍说明业务链路存在问题。

改造价值不只是换了新框架。应观察后续需求是否更容易理解、开发、验证和上线，业务人员是否少做重复工作，系统运行责任是否更清楚。

Microsoft 的 Strangler Fig 架构说明提供了通过入口分流逐步替换的技术思路。具体项目仍需结合依赖、数据和组织条件选择边界，避免把某一种架构模式套用到所有系统。