我有如下客户端要求，以如下方式升级现有的TFS（Azure DevOps Server）实例：
目前的重点仅在于第一次升级，因此最后两个迁移现在可以忽略。
我们的整个TFS实现（应用程序和数据层）都托管在单个服务器上-Windows Server 2008 R2 Enterprise。该服务器还为TFS数据库运行SQL Server 2008 R2实例。
对于从TFS 2010到TFS 2013的升级，我们打算使用以下硬件：
期望最好，为最坏的情况做准备。最重要的一个您可以在此处采取的步骤是确保您拥有完整且一致的数据库备份集。注意：备份之前先删除集合
然后迁移到Azure DevOps 2019，您需要最低版本的Windows Server 2012（因此无需更改VM），但您需要升级到SQL 2016 SP1，这是AzDo 2019的最低要求。您只需要运行AzDo 2019的安装，它将就地升级2013到2019。
为了确保没有冲突，请确保使用this更改TFS 2013中的服务器SID，>
在AzDo 2019中，进行非生产升级，它将为您解决这一问题。
最后，升级到2019（就地）后，您可以运行迁移向导并转到云中
所有要求都可用here
这是一次完整的迁移升级（不是就地升级），因此，使用新的/替换硬件完成了向更高版本的TFS版本的迁移。
这两项升级都是根据Mohamed Radwan出色的YouTube教程完成的，该教程可以在here上找到，并且严重依赖于TFSBackup和TFSRestore实用程序，这两个版本都随TFS一起提供，我相信自2012年以来。
我的TFS 2010数据库的备份是从TFS 2013实例（一旦安装）的Tools目录中执行的，位于我的应用层的新专用硬件上。
在使用TFSRestore实用程序成功还原数据库之后，通常需要执行三个关键任务，这些任务需要使用TFSConfig工具来确保两个TFS实例之间的数据完整性不会受到损害或破坏。这些是按相同顺序执行的当将部署移至新硬件，但要继续使用旧部署时。
我们没有任何预定的备份，SharePoint或Reporting Services包含在我们的迁移范围内，并且除了几天的迁移升级验证和测试外，我们当然不打算长期使用旧的部署。因此，我忽略了该错误。
ChangeServerID
命令成功运行，这将确保两个实例现在无论如何都是离散的，并且已经分配了唯一的GUID。幸运的是，ChangeServerID任务成功完成。然后我也执行了
RemapDB
命令，但实际上，甚至不需要，因为ChangeServerID命令已经完成了重新映射任务。 从现在开始，迁移就如梦一般，绝对没有遇到任何问题。要添加的另一个关键点是，只有在确保没有用户登录到系统上并且在备份之后，我才使2010实例完全脱机，才完成了TFS 2010实例的备份。TFS 2013到Azure DevOps Server（TFS）2019.1-一些有用的注意事项
再次使用TFSBackup和TFSRestore实用程序（这次来自Azure DevOps Server 2019.1工具目录），并且几乎重复了上一次迁移升级的步骤，我设法一目了然地将我们带到目标2019实例上。
甚至更好，对于Azure DevOps 2019，TFSConfig PrepareClone，ChangeServerID和RemapDB任务已合并到应用程序层配置向导中，这意味着您不需要从命令行手动运行它们。该工具可以为您完整地处理它，非常好！从使用的容易程度和简易性，自动化的大量使用以及显然不会造成灾难的角度来看，我很惊讶不推荐TFSBackup和TFSRestore工具作为当前最好的工具迁移选项，当然要取决于目标迁移的类型。
希望此反馈将帮助下一个踏上类似旅程将TFS从2010年版本升级到更高版本的下一个人。