Rules to Better TFS 2010 Migration - 12 Rules

There are many options for migrating to TFS 2010 from TFS 2008.

1. Prepare a new image. We recommend running Windows 2008 R2 Server x64using Hyper-V Manager. Your options are:
   1. Manually build a server
   2. A syspreped image (this will be quicker)
   3. System Center Virtual Machine Manager (recommended, quickest)
2. Add the roles
   1. Application Server
   2. IIS
3. Install SQL Server 2008 x64 default configuration
4. Install SQL Server 2008 SP1
5. Run www.ssw.com.au/ssw/Diagnostics/ and get all green ticks

Once you are ready to start you need to make sure that no one can access the existing TFS 2008 server while you do the migration.

1. Run the excellent DogFoodStats by Grant Holliday. These are queries on the TFS2008 database to give you stats about number of files, number of users etc. http://blogs.msdn.com/bharry/archive/2007/12/02/tfs-statistics-update.aspx 1. Record the Number of files 2. Record the number of Iterations

TFS2008:

===========================================

Files

1        28052

2        335168

-- Compressed file size:

11837952896

-- Uncompressed file sizes:

24868196032

-- Areas & Iterations:

1096

Example: Dog Food Stats on TFS2008 Make sure that you save the numbers so you can compare it to TFS 2010 later...

Run your daily backups to provide a safety net should things go wrong.

Since we recommend doing a "move based upgrade", we don’t like the "in place upgrade" option, these are the steps:

1. Copy the TFS2008 backups to TFS2010 server (e.g. C:\TfsBackups)
2. Restore all the databases to TFS2010’s instance of SQL 2008
3. Install Team Foundation Server 2010
4. After the install has completed the Team Foundation Server Configuration Wizard will open
5. Select Upgrade | Start Wizard 
6. Click "Next" 
7. Click "List Available Databases"
8. Select the TfsIntegration database
9. Check "By checking this box, I confirm that I have a current backup"
10. Click "Next" 
11. Select "NT AUTHORITY\NETWORK SERVICE" for the System account
12. Click "Next" 
13. Click "Next" 
14. Click "Next" 
15. Click "Next" 
16. Click "Next" 
17. Specify the TFSService account
18. Click "Next" 
19. Click "Next" 
20. Click "Next" 
21. Click "Next" 
22. Click "Next" 
23. Click "Configure" 
24. Have coffee (2 hours) BTW: A good user interface should have a coffee image [TODO: Martin to create new rule in "Rules to better UI"] [TODO: Martin to add suggestion to TFS] 
25. Click "Next" 
26. Click "Close" 
27. Click "Close" 
28. Change the DNS entry for tfs.northwind.com to point to TFS2010 on
    1. Internal DNS
    2. External DNS

Since you have to deal with your system admins, this job will take the longest. Speed it up by buying a Red Bull for your system admin

All of the hard work has been done, now you need to do a quick test.

Running the "Dog Food" stats on your new TFS 2010 server is a good way to see if the upgrade was successful. You should check the new values against the stats you noted down from your TFS 2008 server.

Getting someone else to test the migration is the best way to make sure that you have not missed anything.

If you have already done some test migrations on the new server there is no need to start from scratch. Just follow these simple steps and you will be up and running in no time.

1. Open the Team Foundation Server Admin Console
2. Click Application Tier | Team Project Collections | Detach Team Project Collection  Figure: Remove the old Team Project Collection from the server.
3. Delete the Tfs_* databases except Tfs_Configuration from SQL Server Management Studio
4. Delete the Tfs_Analysis database from SQL Server Analysis Server.
5. Copy the TFS2010 backups to TFS2010 server (e.g. C:\TfsBackups)
6. Restore the databases to the TFS2010’s SQL 2008 Server
7. In the Team Foundation Server Admin Console
8. Click Application Tier | Team Project Collections |Attach Team Project Collection 
9. Follow the wizard, rule #8 from step 13.

If you are going to be integrating TFS 2010 with SharePoint 2010 then there are a few things you need to do.

Most of your reports (built in and custom) will be broken as the database schema has significantly changed.

To be ready for this, do a test migration and update any custom reports against the new database schema. That way, when your live server is up and running, your reports will be ready.

See John Socha-Leialoha's post for a good write up about what has changed and how to get your reports working.