We are currently using TFS 2008 with the Scrum for Team System template from Conchango, with a few minor tweaks. We are looking at upgrading to TFS 2010 and we are considering moving to the MSF for Agile template.
What is the best way to move to a new process template and keep history? I’d like to be able to create a new team project on the TFS 2010 server, get everything checked-in, and move our source to the new project. It would be nice if we could somehow keep the check-in comment history and possibly even be able to navigate back to the work item history associated with a changeset in the old project. I’d even be willing to migrate the old project as-is over to 2010 and then move the source to a new project, retaining the old project with work items only in 2010.
Has anyone gone through the process that can over some advice?
We are in a simalar situation that you are (right down to the templates we are on versus the one we want to be on), although we only have source code in our existing Team Foundation Server instance. We are planning to do a migration from Team Foundation Server 2008 to Team Foundation Server 2010, as opposed to an upgrade. Although we have not done so yet, you do have the have two options you have outlined.
Like you mention, you can migrate the source code and Work Item Tracking to a new Team Project using this tool. It will “compress” the history dates, as TFS will want to add its own timestamp. There will be some potential history issues, from what I understand. Specifically, in TFS 2010, you might have issues comparing versions from the pre-migrated source control. At least, so far, I have in my experiments in our test lab. My understanding of this issue is that it relates to item-mode vs. slotted-mode as the defaults between the two versions. I can look at individual versions and can see history – so that meets our requirements.
The other option is source control in one project and work items in another. I have not tried this, because I would imagine that the changeset relationships would be broken on existing work items and would not be generated going forward. This may or may not a be a big deal to you.
Also, it might be a good idea to describe your situation in the discussion area of the project on Codeplex. The authors are on the TFS Migration Team at Microsoft and depend on feedback of people in the same boat we are. I have been exchanging a couple of emails with them so far, and they have been quite helpful.
Based upon our discussions with the very helpful folks at Microsoft, we are likely going to backup the databases and follow the directions on Bryan Krieger’s blog post (Path 2: Migration Upgrade). I am hoping to make a test run at the upgrade using an older backup as early as next week.
Best of luck! I know it is intimidating. Luckily, my installation and configuration experiences with a fresh TFS 2010 install in the lab have been much more smooth than my initial exposure to the TFS 2008 process. Hopefully, you find the same is true.