TFS 2017升级至2018的实施计划是否存在明显漏洞？
你的升级思路整体方向是对的，但有几个容易被忽略的细节可能导致升级失败或后续问题，我帮你逐个拆解：
1. 日志传送的收尾一致性问题
日志传送的最后一步必须在TFS服务完全停止后做最后一次日志备份并恢复到新SQL实例。如果在TFS还在运行时完成最后一次日志备份，数据库会存在未提交的事务，恢复后的数据会不一致，直接影响后续升级。建议调整步骤顺序：
- 先停止TFS服务（包括应用层、作业代理等所有相关服务）
- 对旧SQL的TFS数据库做最后一次日志备份
- 在新SQL上恢复这个最后备份（使用
RECOVERY参数完成恢复）
2. SQL权限的认知误区
你提到“数据库权限因是副本无需额外考量”，这里有个关键问题：数据库用户和SQL实例级的登录账号是分离的。日志传送只会复制数据库内的用户，但新SQL实例上没有对应的SQL登录账号（比如TFS服务账号、报表服务账号的登录）。你需要：
- 用
sp_help_revlogin脚本导出旧SQL的登录账号和密码哈希，导入到新SQL实例 - 确保TFS服务账号在新SQL实例上拥有所有TFS数据库的
db_owner权限，以及SQL实例的Alter Any Server Role等必要权限（具体可参考TFS安装文档的权限要求）
3. 代理作业的完整性缺失
复制代理作业时，除了排除日志传送作业，还要注意：
- SQL Agent的凭据、代理账号是实例级的，不会随数据库复制，需要手动迁移或重新配置
- 检查TFS相关的作业（比如数据仓库同步、作业队列清理）的执行账户在新SQL上是否有足够权限，避免升级后作业失败
4. TFS服务与SQL切换的顺序问题
你的步骤4（关闭SQL2014）→步骤5（将TFS指向新SQL）存在风险：如果TFS服务还在运行，关闭旧SQL会导致TFS连接中断，可能引发数据损坏。正确顺序应该是：
- 停止TFS服务
- 关闭旧SQL Server 2014
- 修改TFS配置指向新SQL实例
- 再启动TFS服务进行后续升级
5. SharePoint数据库删除的前置操作
直接删除SharePoint相关数据库前，必须先在TFS管理控制台中解除与SharePoint的集成。如果TFS系统中还残留着SharePoint的关联配置，直接删数据库会导致TFS出现异常错误（比如页面加载失败、配置读取错误）。建议先确认集成已完全移除，再删除数据库。
6. 缺失预升级检查和备份环节
升级前的两个关键步骤你没提到：
- 在新SQL实例上恢复数据库后，运行
TfsConfig PrepUpgrade命令做预升级检查，这个工具会扫描数据库是否有损坏、权限是否达标、是否符合TFS2018的要求，提前发现问题 - 对新SQL上恢复后的所有TFS数据库做一次完整备份，避免升级失败后无法回滚
7. 报表/分析服务的迁移遗漏
如果你的TFS环境配置了SSRS报表服务或SSAS分析服务，这些服务的数据库和配置也需要迁移到新SQL2016实例，否则升级后报表、数据仓库功能会完全失效。需要同步迁移这些服务的数据库，并重新配置TFS与它们的关联。
8. 网络与防火墙配置验证
确保TFS服务器能正常访问新SQL实例的端口（默认1433），防火墙规则已开放相应端口，DNS解析正确。很多升级失败都是因为网络连通性问题导致TFS无法连接新SQL。
内容的提问来源于stack exchange，提问作者Bill Greer
