Migration to TFS 2010

by Aaron 17. May 2010 09:10

We recently migrated from Team Foundation Server 2008 to Team Foundation Server 2010.  Here's the scenario that we had:

  • New Active Directory domain
    • The domain was built new and not migrated from the old domain
    • As a result, the users were brand new user accounts with no SID history
  • New server hosting TFS
  • The TFS data was now going to be stored on a separate SQL Server instance instead of having everything contained on a single server
    • The old instance of TFS was using SQL Server 2005
    • The new instance of TFS is using SQL Server 2008 with an instance of SQL Server Reporting Services
  • We weren't concerned about retaining version history, work item history, or closed work items
  • We didn't want to keep all of the projects, just some of them
  • We wanted to move from Scrum for Team Systems 2.2 to Scrum for Team Systems 3.0
  • We weren't concerned about the data in SharePoint
  • We weren't concerned about the reports in SQL Reporting Services

I read through this after writing it and decided that some people may be interested in the "short" version.  So, to save you from having to read my monologue, I've created a bulleted summary.

To summarize what we did to accomplish our migration:

  • Install the new instance of TFS 2010
  • Wire up the new instance to a separate SQL Server 2008 instance with SQL Server Reporting Services
  • Back up the databases from the TFS 2008 instance, and export the SQL Server Reporting Services encryption key
  • Restore the databases on the new SQL Server instance
  • Run Tfsconfig import /collectionName:UpgradedCollection /sqlinstance:<SQL Instance Name> where UpgradedCollection is a project collection that doesn't yet exist, and is the name you want to use for your new project collection
  • You may have to configure SharePoint and set up the site in the TFS configuration manager for web access.
  • You'll have to configure SQL Server Reporting Services with the encryption key you exported from the old instance
  • If you want to reorganize the projects into different project collections, then if you can get it to work properly, TFS Integration Platform is supposed to be very good.  Take your time to understand it though, which might help you succeed in using it.  I didn't have the time.

And now...the LONG version...

The first thing that we did was stand up the new instance of TFS 2010.  I should clarify that I didn't do that part.  My boss did that part.  I still had a role in the installation though.  I nagged until he finished it, and the whole time I had to listen to the excuses and problems he was having.  It's tough being me.

Once he got that part done, it was up to me to figure out how to get the source code from the old TFS 2008 server into the shiny new TFS 2010 server.  I looked into the different methods that were available to me for migrating the data.  Probably the best information that I had available to me for this was the TFS installation documentation.  It's a bit extensive and makes reference to a lot of OTHER pieces of documentation, but it was helpful.

At first, I looked into using the TFS Integration Platform to migrate the code from TFS 2008 to TFS 2010.  After trying several times, I discovered that I really wasn't going to be able to connect to the database in the old domain as well as the database in the new domain.  I began looking into other options.

I settled on putting the data in the new TFS installation, and upgrading it to the 2010 format.  I did some searching around, and I found it's not difficult to do.  The TFS documentation links to a bunch of different places to tell you how to do it.  In a nutshell, back up all of the databases on the TFS 2008 database.  You'll recognize which ones they are by the "tfs" prefix on each one.  The databases will probably also be named after their corresponding project.  There are SharePoint databases also.  If you have SharePoint data, you'll need those databases also.  And finally, if you want to keep the reports from SQL Server Reporting Services, those databases are fairly easy to recognize too by the name.

The easy way to get all of the databases is to create an on-demand maintenance job.  That job will allow you to choose all of the databases to do a complete backup.  If you're backing up the Reporting Services data for restore in the new TFS instance, which we didn't, I can tell you that you need to back up the encryption key in the Reporting Services configuration console.

I restored the databases to the new database server.  I even restored the SharePoint databases, just in case.  I ignored the Reporting Services databases.

After the databases were restored, I went through the process of upgrading those databases.  I referenced a post on Brian Harry's blog for migrating the data.  The tfsconfig import command changed a little bit since that article.  It should be something like:

Tfsconfig import /collectionName:UpgradedCollection
/sqlinstance:<SQL Instance Name>

The connectionString is no longer a valid option.  Also, the "UpgradedCollection" named by the "collectionName" parameter must be a collection that doesn't exist.  I tried doing this with an empty project collection that I created, but of course it failed.  It failed because you're creating the project collection with the command.  So...don't do it.

You should note that the project collection is comprised of all of the projects that you had in the old TFS instance.  I'm not sure if you can specify individual projects to put into the project collection.

Because we only wanted some of the projects, I again tried to use the TFS Integration Platform.  Again, it was without success.  Actually, it told me success, but it lied.  The only way it could lie more is if it told me how cool and good-looking I am.  I'm on to you TFS Integration Platform...

So as a last resort, I decided to get the code out of the project, and add it to the new one.  That means that you have to get latest version in Visual Studio, remove the source control bindings, switch to the new project, then add all of your stuff as new files.

The next thing was moving the work items.  Since TFS Integration Platform let me down, I decided to try the witadmin command line utility.  After exporting all of the work items out of TFS, I had to go through some clean up on the XML to get the import to work.  Or at least, that's what I thought.  Again, it was giving me success messages, but it wasn't working.  I think it must have partnered up with the TFS Integration Platform in an attempt to make my life miserable.  I won't say if their plan worked or not.

Finally, I decided to simply use Excel.  TFS integrates with Excel for managing work items.  If you've never used it before, it's less painful than using Team Explorer 2008, but only slightly.  To actually create the work items as new work items, I had to make some updates to them.  They were finally migrated though.  Fortunately, I didn't have to work with many.  Maybe 100 work items.

That was our migration.  While it was a fairly bumpy road, it's definitely been worthwhile in the long run.  I highly recommend moving into a TFS 2010 environment if you have the opportunity and the resources.

You'll notice that I didn't talk about connecting the SharePoint data into the new TFS 2010 instance.  You can do that through traditional SharePoint configuration.  You may have to use the stsadm command to attach the database.  SharePoint is out of the scope of what I want to talk about.  The information is out there, and if you have a SharePoint guru, you've got somebody with the knowledge to do it.

I also didn't talk about attaching the Reporting Services databases.  Again, once you've restored the databases, you'll have to go through the SSRS configuration to import the encryption key connecting you to the databases.

Good luck!

Tags: , , , ,


Comments are closed