TFS Migration Tools: Wandering into the caves of migration scenarios

  • Article

In recent posts  we looked at the configuration file (VSTS Rangers Project - TFS Migration Tools: Configuration Demystified) and some getting started questions (VSTS Rangers Projects – TFS Migration Tools: Getting Started Questions). The theme of today is to revisit the question whether you should be considering and using the TFS Migration Tools in the first place. It is important that throughout this blog post and investigations involving this tool, you are aware of the major constraints we have not been able to address yet:

  1. Limited to migrating only Version Control items, Work Items, and the links between them, “excluding” other data such as Reports, Team Build data, and SharePoint content.
  2. Work Item IDs and Changeset numbers are not preserved during migration and new IDs are assigned sequentially as items are migrated.
  3. Timestamps on work item revisions and changesets will be updated to the time of migration, which has significant impact on those relying on a time dimension such as Bug Trends and Code Churn.

The solution guidance, which will be released in due course as part of the VSTS Rangers bits, talks about four main scenarios and some mutant derivatives, all of which we will quickly skim through. It is important to realise that we are neither wanting you to use or not use the TFS Migration Tools in this blog post or related product guidance, instead we want you to understand the constraints, understand your requirements and scenarios and most importantly, not use the TFS Migration Tools for the wrong scenario or reason … it is not a silver bullet and has been used for the wrong reason in the past, resulting in unnecessary confusion and frustration.

Common Scenarios

image … common scenarios flowchart from guidance document

Upgrade

image When we move from old hardware to new hardware we talk about a “move based” upgrade and when we stick with the same hardware and just want to upgrade the software, we refer to an “in-place” upgrade. For both of these two upgrade scenarios you should refer to the standard Team Foundation Server (TFS) installation guide in place of the TFS Migration Tools.

Consolidate

image If we are consolidating TFS 2005 and TFS 2008 servers servers onto one TFS2008 or TFS 2010 server we could consider the TFS Migration Tools, if and only if the constraints mentioned upfront are not an issue. In an all-TFS 2010 consolidation, however, we should again refer to the standard TFS Administration Guide and the forthcoming TFS Upgrade Guidance from the VSTS Rangers for more information before considering the TFS Migration Tools.

Migrate

image If we are not migrating from TFS to TFS environments we should look at https://msdn.microsoft.com/en-us/teamsystem/bb840033.aspx for standard off-the-shelve solutions that are specialised in the non-TFS environment. If we are moving between two TFS environments, we should again refer to the TFS administration and installation manuals, considering the standard scenarios for moving a TFS Server to another TFS Server in favour of using the TFS Migration Tools as the mentioned constraints can have a significant impact. If you end up in the fall through bucket, i.e. none of the standard solutions will work for you, you can consider the TFS Migration Tools re-using existing adapters or developing custom adapters on top of the TFS Migration Tools. The latter is covered in the forthcoming VSTS Rangers guidance and documentation.

Synchronise

image The same arguments as for the migrate scenario applies to the synchronise scenario, which in essence is a two way, on-going migration. Consider standard and specialised off-the-shelve solutions. If all else fails and you are staring at the fall through bucket again, consider the TFS Migration Tools.

 

Special Mutant Scenarios

In the guidance we are mentioning two special mutant scenarios, namely the Phased Migration, see VSTS Rangers Projects – TFS Migration Tools: Where has the link relationship vanished and why? for details, and the Move to another process template scenario, see VSTS Rangers Projects – TFS Migration Tools: Query => Is the migrating from one process template to another a plausible scenario? .

Both these scenarios are going to be common when TFS2010 is released and TFS environments are looking at migrating existing environments to TFS 2010 environments. Another scenario we are investigating is the Divide a team project into multiple ones, which will be covered in future guidance.

In the Next blog post in this serieswe will take a look at the Mutant “Move to another process template” scenario, moving from a team project based on a TFS2008 Agile process template to a team project based on TFS2010 Agile process template, the associated configuration and the tools at our disposal.