TFS 2010至2018跨新硬件与域迁移及升级顺序咨询

我之前经手过好几次类似的TFS跨版本+跨域+硬件迁移项目，结合实际运维经验给你梳理下核心要点：

完全可行，但必须严格遵循微软官方的版本升级路径和SQL迁移规范。你提到的「TFS2010→TFS2013.5→TFS2018」过渡路径是正确的——微软明确要求TFS2010不能直接升级到2018，必须经过2013或2015版本过渡；SQL Server 2008 R2到2017的迁移也是支持的，只要注意数据库兼容级别的调整。

强烈建议优先在原环境完成版本升级，再迁移到新域的新硬件，原因和具体步骤如下：

• 原环境升级风险可控：原环境有成熟的备份、权限和依赖体系，出问题可以快速回滚。先在原环境完成从2010到2013.5，再到2018的升级，能提前验证构建、工作项、用户权限等核心功能的兼容性，避免迁移后再发现版本问题。
• 避免多变量叠加故障：如果同时做「版本升级+域迁移+硬件更换」，一旦出问题很难定位是哪个环节导致的（比如权限失效可能是域迁移的锅，也可能是升级后的权限逻辑变化），分开操作更便于排查问题。
• 具体执行步骤参考：
  1. 先对原环境的TFS所有数据库（配置库、集合库）和SQL Server实例做完整备份，确保回滚基础。
  2. 在原域内搭建临时的TFS2013.5服务器，将备份的TFS2010数据库恢复过去，执行升级操作，验证构建任务、工作项流程、用户访问权限全部正常。
  3. 从TFS2013.5升级到TFS2018，再次全面验证核心功能：比如旧的XAML构建是否能正常运行，自定义工作项字段/规则是否保留，报表是否正常生成。
  4. 备份验证后的TFS2018数据库，迁移到新域的SQL Server 2017实例，手动将数据库兼容级别从默认的100（SQL2008R2级别）修改为140（SQL2017级别）。
  5. 在新域的新硬件上安装TFS2018，配置连接到迁移后的SQL数据库，完成新域用户映射、构建代理重新配置、客户端连接测试等收尾工作。

这些都是我踩过的坑，一定要注意：

• 版本升级路径错误：绝对不能跳过TFS2013/2015直接从2010升2018，否则会触发数据库升级失败，甚至损坏原数据。
• SQL兼容性遗漏：SQL2008R2数据库恢复到2017后，默认兼容级别还是旧版本，必须手动修改为140，否则TFS2018会出现查询性能下降、部分功能无法使用的问题。
• 域迁移后的权限混乱：新域用户的SID和原域不同，直接迁移会导致用户无法访问工作项、丢失构建权限。建议要么用AD迁移工具迁移用户SID历史，要么在TFS升级完成后，手动映射原域用户到新域用户。另外，构建代理的服务账户必须换成新域的账户，确保能访问TFS服务器和构建资源。
• 构建与工作项兼容性问题：
  • TFS2010的XAML构建在2018中支持有限，部分复杂的XAML定义可能无法正常运行，建议提前测试，必要时迁移到TFS2018的基于任务的新构建系统。
  • 自定义工作项模板、字段规则要重点验证：升级后自定义字段是否丢失，状态转换、必填规则是否正常，避免出现工作项无法创建/编辑的情况。
• 备份与回滚机制缺失：每一步操作前都要做完整备份，包括TFS数据库、SQL系统库、TFS配置文件。如果升级或迁移中出问题，能快速回滚到上一个稳定状态，避免业务中断。
• 网络与依赖遗漏：新域环境要确保网络连通性：TFS服务器能访问SQL实例，构建代理能访问TFS和代码仓库，用户客户端能正常连接新TFS；另外，依赖的第三方工具（比如测试管理工具、集成的CI/CD工具）也要提前验证在新环境下的兼容性。

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