TFS服务器丢失但后端SQL Server完好，求迁移源码至VSTS的可行方案

嘿，你遇到的这个情况其实挺典型的——应用层炸了但数据层完好，先给你拆解下你的两个思路可行性，再给你几个靠谱的替代方案：

你的思路分析 #

1. 直接从SQL导出数据导入VSTS #

这个路子走不通。VSTS（现在正式改名叫Azure DevOps Services了）的底层存储架构和本地TFS完全不一样，微软根本没提供直接导入TFS SQL备份的方式。而且要注意：TFS的源码不全存在SQL里，大部分实际的文件是存在TFS服务器的本地磁盘仓库中的，SQL里只存元数据和索引，就算你能导出SQL数据，也没法直接转换成VSTS能识别的格式。

2. 新虚拟机装TFS连接现有SQL #

这个方法完全可行，甚至是我最推荐的第一步！TFS的核心业务数据全在SQL Server里，只要你搞定这几个关键点：

• 必须安装和原TFS一模一样的版本（包括补丁），版本不匹配的话根本连不上数据库；
• 新TFS的服务账户得有SQL里TFS数据库的完整权限（比如db_owner角色）；
• 如果原TFS的源码是存在本地磁盘的（不是SQL的Blob存储），得把原服务器上的仓库文件夹（默认路径大概是C:\Program Files\Microsoft Team Foundation Server xx.0\Version Control）完整拷贝到新服务器的对应位置，不然TFS能读到元数据，但找不到实际的源码文件；
• 安装完TFS后，运行配置向导选「应用层只安装」，然后指向现有的SQL数据库，就能重建出一个功能完好的TFS服务器了。

等TFS恢复正常，你就可以用官方的迁移工具把项目迁去VSTS了。

其他可选方案 #

要是重建TFS的条件满足不了（比如丢了磁盘上的仓库文件），可以试试这些替代办法：

• 从本地工作区抢救：如果开发人员本地的TFS工作区还留着完整代码和历史，可以让他们把本地仓库转成Git（用tf git clone或者直接初始化Git推送），再上传到VSTS的Git仓库。缺点是集中的分支历史会乱，适合小团队或者历史记录没那么重要的情况。
• 从SQL里提取源码：TFS的版本控制元数据和部分文件片段存在SQL里，你可以用第三方提取工具或者自己写脚本扒出源码和历史。但这个技术门槛高，很容易丢数据或者搞坏历史，只能当最后一招。
• 官方导入服务兜底：只要能重建TFS服务器，Azure DevOps的官方导入服务能完整迁移源码、工作项、构建历史所有数据，这是最安全靠谱的方式，支持TFS 2013及以上版本导入到Azure DevOps Services。

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