Wednesday, July 19, 2017

#DevOps Series: Upgrading Microsoft Dexterity VSS and TFS repositories to Visual Studio Team Services - Part 2/2

Continuing with our #DevOps series, today we will address the upgrade process from Team Foundation Server (TFS) to Visual Studio Team Services (VSTS). Yesterday, we addressed the upgrade from Visual SourceSafe (VSS) to VSTS - see #DevOps Series: Upgrading Microsoft Dexterity VSS and TFS repositories to Visual Studio Team Services - Part 1/2, - and saw all the important steps needed to ensure your Microsoft Dexterity repository is migrated properly. Likewise, you must observe a series of steps prior to moving your TFS repository to VSTS.


One of the main questions I usually field around this topic is, "Why would I want to move from TFS to VSTS?" The truth is, there are a number of reasons that you may want to consider: a) less server administration, b) a cloud solution gives you immediate access to the latest and greatest features, c) improved developers' connectivity - personally, I love the ability of being anywhere in the world and having access to our repository, without having to establish a VPN connection to some server; and d) if you want to keep the finance people happy, just tell them that you are moving from a CapEx model (servers and hardware that needs to be depreciated, with iffy tax deductions) to an OpEx model (subscriptions that are fully tax deductible).

Once you can see through the benefits, it will be easier to adopt VSTS. The next question is usually, "What are the differences between the two?" For a primer on this, and to keep the article tight, take a look at the following whitepaper:

Fundamental differences between TFS and Team Services

Migrating Microsoft Dexterity repositories from Team Foundation Server to Visual Studio Team Services

As with VSS, there are a few acceptable methods to migrate from TFS to VSTS, as follow:

1) Manually. You can copy the most important and perhaps, the latest projects you are working on. When you are done, you can simply mark off the TFS projects as read only. Under this scenario, the assumption is you will be leaving behind your old TFS server to maintain the history of all your old projects, but if you are getting rid of the server (which is the main reason to move to begin with), you may want to consider a different method.

2) Use the Database Migration tool. As you all know, I am a fan of tools that allow you to automate the process and minimize any risk associated with moving data from one place to another, especially over the internet. The Migration Guide is available here. However, this particular Microsoft tool was very young when we first looked at it, and as of the writing of this article, it was still in preview mode.

3) Use a third-party tool. Frankly, when we did our migration here at Mekorma, we tested a number of tools, but settled on the OpsHub Visual Studio Online Migration Utility, available for free from the Visual Studio Team Services gallery.

Visual Studio Online Migration Utility

OpsHub Visual Studio Online Migration Utility Free Version helps developers migrate the most commonly requested data from an on-premises Team Foundation Server to their Visual Studio Team Services account.  It enables basic migration of history of version control change sets, work items, test cases

The Free Utility is limited to migrating projects with less than 2500 revisions of work items and less than 2500 revisions of source control. The Free utility offers very limited support thru the community supported Q&A forum with no additional support included.

But rather than me trying to describe all the steps, I thought it would be best to embed the demonstration video here:

Tomorrow, I will show you how to leverage Visual Studio Team Services' Build process to extract and chunk your Dexterity applications.

Until next post!

Mariano Gomez, MVP

No comments: