方案很对，迁移却没人买单

新方案吞吐更高，接口也更干净，演示时几乎挑不出毛病。可评审结束以后，没人愿意把现有业务迁过去。

提出方案的人很容易得到一个结论：他们守旧，他们看不懂。

最近读到一篇文章，里面讨论一个新观点是否因为出现得太早而遭遇失败。原文使用了一位未具名历史医生的故事，我无法从这份收藏里核实具体人物和经过，所以不把它当事实写进来。但“正确为什么没有自动变成采用”这个问题，放到软件和产品里很具体。

技术正确只回答了一个问题：新方案在目标条件下是否更好。迁移还要回答另外三个问题。

旧数据怎么过去，切换期间能不能同时运行；出了问题怎样退回，谁来判断已经到了回退点；迁移占用的时间由哪个业务目标让路，结果不好又由谁承担。

这些问题听起来不如架构图漂亮，却决定了团队眼里的真实成本。对提出者来说，旧系统的问题每天都很刺眼；对正在交付的人来说，新方案首先意味着一段额外工作，以及一批尚未暴露的故障。

假设要替换一套正在运行的任务系统。直接要求所有业务停下来重写，证明的是决心，不是可行性。更窄的做法是先挑一个可回放、可对账、失败后能切回旧链路的任务，让两套结果并行一段时间。

这个例子是迁移思路，不是对任何真实系统的描述。它的价值在于把争论从“你信不信新方案”，换成“同一批输入，两边结果是否一致，故障时能否恢复”。证据开始积累，采用才有可能从立场问题变成工程问题。

我以前也容易被“明显更好却推不动”激怒，仿佛正确已经完成了全部工作。可如果只有提出者看得见收益，所有迁移成本都让别人支付，阻力并不神秘。

新方案需要的不只是证明旧方案落后，还要给使用者一条过得去的路。方向正确是起点；兼容、对账、回退和责任，才是那座真正要有人付钱修的桥。

资料：

来源