一个已经运行多年的 .NET 系统，通常承载了大量不在文档里的业务约定。它可能并不容易维护，但“全部重写”也不是天然更可控的选择。比较方案时，应把现有业务覆盖、切换方式、数据迁移和失败后的恢复路径一起列入计划。
第一阶段：建立现状基线
先说明系统服务哪些业务、依赖哪些外部接口、有哪些定时任务和人工处理步骤。记录主要部署环境、运行时与依赖版本、构建方式、关键数据表，以及最近出现的问题。技术版本升级、业务重构和部署方式调整是不同工作项，应分别识别影响范围。
此阶段可以形成三份材料：系统与依赖图、关键业务回归清单、风险与未知项清单。对于缺少自动化测试的系统，先为高价值流程建立能够重复执行的验证步骤。
第二阶段：选择一个可以控制范围的试点
试点不一定是最复杂、最紧急的模块。更适合讨论的是：职责较明确，外部依赖可以梳理，具有可验证收益，而且发生问题时影响范围可控的业务能力。需要同时明确试点包含什么，以及哪些关联功能继续留在原系统。
微软介绍的Strangler Fig 渐进式迁移模式强调逐步替换旧系统能力，而不是一次性完成整个系统的切换。这个思路能帮助规划新旧系统并行期间的边界，但并不自动解决数据迁移和恢复问题。
第三阶段：先接通兼容路径，再转移业务职责
明确新旧接口如何共存、请求如何路由、调用方如何升级。对于响应字段和错误语义，列出兼容要求。可以在测试环境回放请求验证，但对支付、下单和通知等有副作用的操作，不能未经设计就复制到新旧系统同时执行。
入口切换应有明确条件，例如关键流程通过、观测数据齐全、异常率达到事先约定的要求。条件应结合系统基线制定，不套用一个通用阈值。
第四阶段：把数据迁移作为独立任务验收
- 迁移哪些数据，迁移期间谁拥有写入权？
- 如何同步增量，如何识别遗漏、重复和冲突？
- 新旧数据结构是否兼容，如何进行对账？
- 切换后如果已有新数据写入，回退需要怎样的补偿或恢复步骤？
回滚旧版本程序，不等于业务数据已经回到旧状态。数据兼容、恢复演练和责任人需要单独确认。
第五阶段：演练、切换、观察，再扩大范围
在约定环境完成构建、部署、健康检查、故障注入或异常场景验证，并演练恢复步骤。生产切换前确认操作清单、观察窗口、停止条件、负责人及通知方式。上线后保留足够的观察与复核时间，再评估是否继续迁移下一部分。
第六阶段：结束旧路径并完成交接
当新路径稳定且相关调用方迁移完成后，再按计划停用旧接口、重复任务和多余资源。同步更新架构图、操作手册、监控告警与资产清单。一次试点应留下团队可以复用的迁移方法，而不只是一个新服务。
对于具体系统，可以先围绕一个模块进行评估，输出阶段边界、业务验证清单、数据切换方案和回退限制，再决定是否进入实施。