In the final post on our migration from TFS to VSTS we will focus on the build components of TFS. This includes build definitions and task groups.

In the last post we migrated the areas, iterations and queries. With that out of the way we can now migrate the work items. This is by far the most difficult and time consuming part of the process. For our migration we had some pretty stringent requirements which made the migration harder. Things to consider include the items to migrate, the links to include, the changes in the IDs, the user identities, attachments and images and whether history needs to be retained.

Next in the series on migrating from TFS to VSTS we will work on moving the areas, iterations and queries. This will set us up for migrating the work items next.

The last article in this series discussed how to use the migration tool to move from TFS to VSTS. In this article we will discuss the code, why things work the way they do, suggestions for improvements and areas that can be modified to customize the tool for your specific needs.

Part 1 – TfsMigration Tool
Part 2 – Migrating from TFVC to Git
Part 3 – Migrating Areas and Iterations

My company recently migrated our on-premise TFS 2017 server to VSTS. There were a variety of reasons for doing so including faster updates, less maintenance for us and cleaning up a system that has been upgraded for years and had a lot of baggage. This series of posts is going to discuss the approach we took, the issues we had and (most importantly) provide code to help anyone else who has to go through the same process.

We have slowly been migrating our XAML builds to TFBuild. After having blogged about how we created custom build tasks we were finally ready to start transitions our builds. At our company we have basically 3 different kinds of builds – ASP.NET apps, console applications and REST APIs. Using XAML builds our deployment process was configured to look for the _PublishedWebsites directory for ASP.NET apps but that doesn’t get created in TFBuild. Hence I spent some time looking for a solution.

In the last post I demonstrated how to create a build task for TFBuild that showed the build variables. I also demonstrated how to wrap the task in a build extension that could be installed in TFS, on-premise. In this post we’ll add another task to the extension. This serves two purposes. Firstly it demonstrates hosting multiple tasks in a single extension. Secondly it demonstrates a more common build task, versioning assemblies.

There are many articles around how to build tasks for TFS 2015’s newer build system (TFBuild). This is yet another one that tries to consolidate the information floating around into a central location and includes information for deploying to an on-premise TFS server.

A while back we wanted to make some changes to our process template. The template was selected back when we switched to TFS 2010 and has been used every since. We’re using TFS 2013 now. The problem is that we had no idea which variant of template we were using. There are several flavors and versions of Agile, SCRUM and even CMMI. Searching online revealed that most people just recommend setting up a new team project but that was out of the question. We had years of history and work items that we didn’t want to migrate. So we opted to go through the tedious process of upgrading our template manually to the latest version before making our customizations. This is a summary of what we did in case anyone else needs to go down this road.

UPDATE 1: Unfortuately not everything is going well with the reports. We were finally able to track down that the issue was with the user account I was using to configure TFS. Evidently you need to be an administrator on the machine hosting the SSRS instance (not just an admin for SSRS). Without admin privileges you cannot access the WMI provider remotely which causes the configuration to fail.  Needless to say the network admins were not pleased. They tried to strip things down to the minimal privileges but nothing short of full admin worked.

UPDATE 2: We have run into another, more serious issue though, we can no longer create new team projects in any collection. I can create a new collection but creating any team project fails. It always fails when trying to create the SSRS reports and the error message is useless. The error message says it cannot connect to SSRS so the host name is bad, the connection timed out or the database is corrupt. Now I’m really annoyed. In a last ditch effort we are rebuilding the reporting databases. If this doesn’t work we may need to retreat back to the old server.

UPDATE 3: Someone from the TFS team responded that all you need to do to move the database is the following:

• Stop the collection
• Backup/restore the database
• Edit the collection settings to move the database

UPDATE 4: We finally resolve the team project creation issue. It turns out that moving the SSRS database and having TFS reconfigure to use it doesn’t restore all the permissions correctly. Thanks to this post I was able to run just the permission update scripts and we’re back in business.

I do see these options in TFS but I’m not sure whether that would include the configuration database (which got moved as well) or just the collection database. The next time I need to move the database I’ll have to try it and see.

Recently we needed to upgrade our TFS 2012 server to TFS 2013. The last time we upgraded TFS 2010 to TFS 2012 it was a nightmare so we took some more precautions this time. Alas they didn’t help. This upgrade proved to be just as big of a nightmare as the last time. Here’s my story of upgrading TFS based upon my 2 previous attempts.