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:
- 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.
- Work Item IDs and Changeset numbers are not preserved during migration and new IDs are assigned sequentially as items are migrated.
- 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.
If we are not migrating from TFS to TFS environments we should look at http://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.
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 series we 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.