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: , , , ,

It's...coming alive!

by Aaron 30. April 2010 09:56

So this is my first blog post.  Not ever, just on here.

I sat on this site and hosting for almost two years.  I kept saying, "I really need to get that done."  I'm still saying that right now actually, because this isn't the look that I want to keep, nor is this the content that I want to push to everybody.  I'm better than that, and you deserve better than that too.

This is going to be primarily a technical blog.  Sure, I'll post the occassional personal post, but I'll tag it as such so that you can ignore it or revel in the fact that I have a real personality.

There were a couple of things that prompted me to finally jsut put something on the internet for the public to read.  The first was an internet business that my wife was going to take on.  I want to discuss some of the things that I took part in (from a technical perspective, not from a husband abandoned perspective) up until she decided that it was going to be too much effort for no gains.

The other thing was Jeremiah Peschka asking me to blog about my experience with a Team Foundation Server 2008 migration to 2010.  I promise, besides this post, that will be the first thing I post.  Hopefully sometime this weekend, but maybe early next week.

From a blog perspective, there were a couple of engines that I was considering using.  I settled on BlogEngine.NET after getting some feedback and doing a little research.  It seemed like it might be an easier engine for me to skin with a theme that I chose and will adapt.  Of course, there are a couple of things that I would like to change with the engine.  At least I wanted to.  I might not need to anymore, but we'll see once I get back into customizing the look and feel.

I chose Godaddy for my domain registration and hosting because I got to purchase the stemen.me domain.  That allows me to host a site for my me, my wife (if she ever decides she wants to take advantage of it, my son, the family dog, and even the creepy kid down the street that eats nothing but saltines and ketchup.  If his last name was Stemen that is.

There are some Windows hosting issues with Godaddy though.  One is that if there's an issue, their support is great, but their turnaround time kinda sucks.  The other is that subdomains point to virtual directories on the web root, if that's how you choose to set it up.  That wouldn't be a problem, except there's a strange issue where the subdirectory is accessible from the subdomain.  For example, http://lucas.stemen.me is URL I keep for my son's blog.  The subdomain points to a folder accessible under http://stemen.me/lucas.  MNot a problem, except that http://lucas.stemen.me/lucas/ also works.  It shouldn't.  But it does.

This wasn't a problem until I started to set up this blog.  If I went to http://aaron.stemen.me/blog, I was redirected to http://aaron.stemen.me/aaron/blog/.  That isn't happening anymore because I have aaron.stemen.me pointing to the root.

I have three solutions: live with it, move on to a better host provider, or come up with a solution.  I actually think I'm going to come up with a solution.  While Godaddy isn't my favorite provider right now, but they're reasonably priced, and I think I can solve it myself.  In fact, it'll be a blog post complete with source code.

The solution that I plan on implementing will be two-fold.  One part will be to make sure that requests coming in get redirected to the appropriate folder and not the extended "wrong" URL.  The other part of the solution will be to make sure that URLs written out in the pages don't contain the subdomain's folder in the URL.  That was the other part that I forgot to mention.  ASP.NET application were saying that the applciation root (~/) resolved to /aaron/blog/ instead of /blog/.

Please come back often, or subscribe to the RSS feed.  I may be visitng your blog too.  I'm a developer, I'm lazy, and I prefer to plagiarize the good work of others.  Of course, anything that I do that with, you'll get credit (and a link) for it.  If you find that I did copy your work or article, but I didn't give you credit, just let me know.  Sometimes I forget.

That's all for tonight.

Tags: , , , , ,