迁移期间同时写入新旧系统，看起来能随时切换，但两边写入并不天然一起成功。只要有超时、重试或并发更新，就可能出现状态分歧。双写方案必须说明最终以哪一边为准。
明确主写入方和失败语义
记录先写哪边、失败时给用户什么结果，以及成功响应丢失后能否安全重试。若两边都允许独立修改，还要解决冲突顺序。不能简单用“最后一次写入覆盖”处理所有业务事实。
将一致性检查作为迁移组成部分
设计按业务标识核对的任务，比较关键状态与金额，而不是只对总数。差异要有分类、处理责任和关闭记录。对账频率取决于风险与允许延迟，不能等到正式切换前才首次比较。
控制兼容写入的生命周期
双写只是过渡安排时，应明确停止条件、旧消费者迁移和任务清理。临时同步代码需要监控、版本和负责人，不能因为“不属于正式架构”就缺少维护。
演练部分成功
人为让第二个写入失败，再模拟重试和恢复，确认不会产生重复业务或覆盖新数据。正式切换前还应核实未完成任务与历史差异是否处理完毕。
常见问题：能否用一个分布式事务直接解决？
需要结合参与系统能力和可用性要求评估。即使技术上可协调提交，也不能替代业务冲突、历史数据和迁移退出规则。
技术参考：微软：渐进式替换模式。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
准备推进现有 .NET 系统改造时，可以先约定一个范围明确的试点。通过单体系统渐进式改造服务梳理边界、兼容与迁移步骤，再按验证结果决定下一阶段。