新接口已上线不等于迁移完成。后台任务、月末报表、历史查询和第三方回调，可能仍然依赖旧系统。退出条件如果没有提前定义，团队会长期维护两套实现，改造成本也持续增加。
找出低频但不可缺少的入口
除了主页面访问，还要检查定时任务、批量导入、结算周期和异常处理工具。不能因为一周没有流量就判断某个接口废弃。先按业务周期记录使用方与用途，再向责任人确认停用条件。
数据一致性需要可核对的口径
比较新旧系统时，说明时间范围、业务状态与允许延迟。仅比较总记录数可能掩盖金额、归属或状态错误。对关键业务抽取明细差异，并明确差异关闭后由谁签认，避免迁移过程中不断改变验收口径。
给并行运行设置边界
确定谁是主写入方，避免两边都认为自己拥有最终状态。保留旧路径的目的、期限和触发回退的条件要写清。如果为了兼容临时增加同步任务，应同时记录监控与未来删除条件。
退役是一次独立交付
先停止新增依赖，再切断确认无用的入口，最后处理账号、任务和资源。保留必要的历史访问或归档方式，并验证恢复资料可用。旧系统退役清单应该与新服务上线清单同样受到评审。
常见问题：旧系统完全零流量才能退役吗？
要区分真实业务调用、健康检查和遗留扫描。对确实需要保留的历史功能，可以提供替代查询方式，而不是无限期保留整个旧应用。
技术参考：微软：渐进式替换模式。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
准备推进现有 .NET 系统改造时，可以先约定一个范围明确的试点。通过单体系统渐进式改造服务梳理边界、兼容与迁移步骤，再按验证结果决定下一阶段。