Killing off TFS 2005: Part 1

Posted 05 April 2011, 14:30 | by | | Perma-link

I'm in the process of upgrading an instance of TFS2005 to 2010, with the added complication of wanting to combine the projects into an existing TFS 2010 Project Collection.

The full series

What am I doing?

As I've had to hunt around on the internet for various steps in the process, I thought I'd try and pull it all together in one place, with the caveat of "it worked for me on my servers", your mileage may vary (considerably) and I take no responsibility for any loss of data, source code, etc. that you may experience (however, I do have to take full responsibility for any loss of data, source code, etc that my team experiences Wink).

To set the scene then, we have the following servers involved in this process, because I want to minimise the downtime that the teams experience while I'm doing this, and the upgrade can't be undone:

  • Missouri - Legacy codebase running on TFS 2005 (upgraded from VSS), using a local instance of SQL Server 2005.
  • Newyork - Current codebase running on TFS 2010 (upgraded from 2008), using a remote SQL Server 2008 instance.
  • TFS10 - Clean install of TFS 2010 using a local instance of SQL Server 2008 for me to play around on.

The three servers: Missouri, TFS10 and Newyork

I found the following resources quite useful as well:

Part 1: Migration Upgrade from TFS 2005 to TFS 2010

These are the steps I took to migrate our TFS 2005 instance (Missouri) to the clean TFS 2010 instance (TFS10):

  1. Copy the latest backup files from Missouri to TFS10 of the following databases:
    • TFSActivityLogging
    • TFSBuild
    • TFSIntegration
    • TFSVersionControl
    • TFSWarehouse
    • TFSWorkItemTracking
    • TFSWorkItemTrackingAttachments
  2. Stop the TFS services using the command line tool found in Tools folder of your TFS installation:
    TFSServiceControl quiesce
  3. Create new databases on TFS10 with the same names as the backups, and restore the backups into these - Note to self: when restoring a database over an existing one, make sure you change the file path on the options pane to the correct destination file path.
  4. Because my friendly SysAdmin had kindly installed TFS for me, opening the TFS Administration Console didn't give me the option of starting the TFS Configuration Tool that's mentioned in the upgrade steps, however, you can run the upgrade process from the command line (again, in the TFS Tools folder):
    tfsconfig import /sqlInstance:tfs10 /collectionName:MissouriImported /confirmed
    Obviously, your SQL Instance and Collection Name will be different, but you get the point.

    This will take a while to run - anecdotal reports are "between 30 and 180 hours", depending on the size of your repository, and the amount of processing resources available. Mine took around 15 minutes on a 10GB version control database and a 76MB work item tracking database.
  5. If all goes well, the command window should report that it's completed "Collection creation step 208 of 208", and that "The Upgrade operation on the ApplicationTier feature has completed. There were 0 errors and 0 warnings.". I can't really advise on what to do if either of those don't happen for you, other than to say "Take a look in the log file", which has quite a lot of detail in it.
  6. Restart the TFS services:
    TFSServiceControl unquiesce
  7. Connect an instance of Visual Studio at the new Project Collection and verify that things look ok. You might also want to try connecting VS2003 (yes, some of the code in there is indeed ASP.NET 1.1, which pretty much requires VS2003, some of it is older still, and is classic ASP/VBScript Sad)

More to follow shortly.

Filed under: TFS