将.NET Framework项目升级为.NET 5时，迁移业务逻辑到.NET Standard 2.0作为中间步骤是否合理？

你提出的分步迁移方案非常合理，是这类中等规模、历史债务较重的.NET Framework项目升级的最优选择之一，优势非常明确： #

• 风险可控：增量迁移的模式下每一步改动范围小，每完成一部分就可以做测试验证，出问题可以快速定位回滚，不会出现一次性全量改代码导致的大面积故障风险，完全可以做到迁移和业务需求并行开发，不会阻塞正常迭代。
• 同步清理历史债务：迁移过程中同步调整依赖注入实现、修复代码质量问题、补充单元测试，相当于借升级的窗口一次性把历史欠账清理完成，迁移到.NET 5之后不需要再单独安排重构工作量，后续维护成本直接降低。
• 兼容性有保障：.NET Standard 2.0本身同时支持.NET Framework 4.7.2和.NET 5+，迁移过程中原有的.NET Framework API服务可以正常运行，不会影响线上业务的正常使用。

原地升级仅适合极特殊场景，你们的情况不推荐 #

只有当你的项目满足代码耦合度极低、所有依赖都有直接支持.NET 5的版本、没有使用.NET Framework独有的专有API三个条件时，才可以考虑用dotnet upgrade-assistant工具做原地升级，否则会面临非常大的问题：

• 全量改动后编译错误排查成本极高，尤其你们原有代码质量较差的情况下，很容易卡在半升级的状态进退两难，反而拉长升级周期
• 无法同步做代码优化，升级完成后低质量代码依然存在，后续还要单独投入资源重构，反而增加整体工作量
• 升级过程中无法并行开发业务需求，整个团队要停下手头功能开发专门处理升级问题，对业务进度影响很大。

针对你的现有方案可以补充几个优化点： #

• 迁移顺序优先从底层公共工具类、基础依赖类开始，再迁移上层业务逻辑，最后处理控制器层，避免出现反向依赖问题
• 遇到暂时没有.NET Standard 适配版本的旧依赖时，可以先给.NET Standard项目配置多目标框架临时兼容，等核心逻辑迁移完成后再统一替换
• 不需要死等所有业务逻辑全部迁移完成再更换Web层，核心逻辑迁移完成后就可以先搭建.NET 5的控制器项目，剩余未迁移的逻辑可以通过.NET Framework兼容模式临时调用，进一步加快落地速度。

内容的提问来源于stack exchange，提问作者herdsothom