Planning an evaluation (or trial) migration/upgrade from TFS 2008 to TFS 2010 seems to be a rather confusing affair; with most Google results still referring to the beta or RC, I haven’t come across many definitive guides pertaining to the RTM release. I haven’t spend any time with the TFS beta either and have never migrated a TFS install so the entire process is new to me. A throwaway install would therefore be required—preferably one that doesn’t impact the production 2008 install!
Most importantly, remember the tfsconfig import is a destructive command. Just stop and think before you do anything—or at least back up your existing databases! Also, a disclaimer: there may be other ways to accomplish the same thing using the upgrade wizard (at install time?? as an in-place upgrade??) but I didn’t follow up this option since I wanted to maintain the existing TFS 2008 environment; it may be worthwhile investigating in your case.
In short, I want to use my existing TFS 2008 data in a clean 2010 environment while the 2008 environment ticks along until the real migration can be scheduled.
1. Install and configure TFS 2010 in a test environment; make sure everything’s working—create a test project collection and project, dill around with it for while, etcetera.
2. Backup the following databases from the data tier running your TFS 2008 environment:
3. Restore the 2008 backups via SQL Server Management Studio to the data tier in your TFS 2010 environment. In my case the 2008 database names were different than the 2010 database names so no name clashes occurred.
IMPORTANT NOTE: Do not follow this advice in production. You’ll likely want to point the tfsconfig import command at your old production server and, if not, there are safer ways to go about the database restore process.
4. Navigate to C:\Program Files\Microsoft Team Foundation Server 2010\Tools in a command window and kick off the import, which will effectively importing from your 2010 environment to your 2010 environment (if pointed to a production server, this process is destructive!):
tfsconfig import /sqlinstance:dev-tfs /collectionName:Imported /confirmed
It took this command 208 steps to do its thing.
Much to my surprise, the TFS 2008 databases restored previously were gone when I next checked in SQL Server Management Studio! Gasp!
5. Open Visual Studio and connect to your new team project(s).
6. Brian Harry also suggests changing the GUID of the migrated database for Beta 2; in my experience, the changeserverid command completed successfully after a warning that I shouldn’t be doing this to “a set of Team Foundation Server databases that have no application tiers configured” but the subsequent registerdb command failed with the following:
TF246017: Team Foundation Server could not connect to the database. Verify that the server that is hosting the database is operational, and that network problems are not blocking communication with the server.
This is a single-server environment with the command being run locally and the database itself is seemingly happy so I doubt a communication problem. At any rate, the mighty Google is silent on this problem and the environment seems kaput—revert, revert! I won’t explore this further as this step isn’t required for a real migration but I suppose it could be related to step 5 where I access the new environment; maybe I should have run these two commands first?
Brian also advises disabling SharePoint and Reporting Services via the Admin Console but I have yet to do that.
Update: After upgrading, we came across an issue where changesets that were previously merged "came back to life" in the merge candidate screen in VS 2010/TFS 2010. This KB article describes the problem and a hotfix is available to correct it. I'm not sure what the official MS stance is on this hotfix but you might want to apply it just in case.
Thanks to http://www.devh.de/post/Team-Foundation-Server-2010-Beta-2-Import-finally.aspx for the Beta 2 steps.