I took advantage of the recent Labor Day weekend to upgrade our systems from Team Foundation Server (TFS) 2008 to TFS 2010. The upgrade went smoothly, so I thought it would be helpful to share my experience so you would know what to expect if you plan to upgrade to TFS 2010.
The previous TFS system was running on a 32-bit installation of Windows Server 2008, the database was SQL Server 2005 64-bit on a separate server, and SharePoint was running on a third server. The first part of the installation was to upgrade the SQL Server. TFS 2010 requires SQL Server 2008 or 2008 R2, and TFS 2008 said it needed SQL Server 2005. TFS 2005 was our only application that still required SQL Server 2005, so I was looking forward to this upgrade so we could also get our SQL Server up to date. (I'm not going into the details of a SQL Server upgrade, but don't forget to back everything up before you do it.) I went for the gold and upgraded to SQL Server 2008 R2; my upgrade went fine, other than SQL Server Reporting Services breaking completely (no surprise there).
After the SQL Server upgrade, I went to do the TFS upgrade, and this is where I learned a major lesson. While the TFS 2010 installer can be pointed to your existing TFS data, it is not a true upgrade but rather a migration. You need to completely uninstall TFS 2008 from the machine; TFS will be reconfigured from scratch, but your data will be migrated and the database schema updated to the TFS 2010 model. If I had realized this upfront, I would have made an entirely new Windows server, so I would be on Windows 2008 R2 64-bit instead of sticking with 32-bit Windows 2008.
After uninstalling TFS 2008, I ran the TFS 2010 installation. It was much, much more pleasant than the TFS 2008 installation (the first time I did it, the install took a week). I'm glad to report that installing TFS 2010 is simply a matter of pointing and clicking through the wizard.
Next, I had to do some post-install configuration to point TFS at the SharePoint server and SQL Server Reporting Services server. The SQL Server Reporting Services side of things took some time to correct, but SharePoint went really smoothly. In all fairness to SQL Server Reporting Services, the upgrade also broke our CRM server's reporting, so I know the issue was not with TFS.
Once the upgrade was finished, I tried it out, and I didn't experience any problems. Some of our clients needed to remove the TFS server from Visual Studio and add it again to make things link up properly. My clients using TFS Team Web Access needed a new URL since Web access is baked directly into TFS now.
Overall, I was pleased with the upgrade process. Even though an upgrade is more hazardous than a fresh installation, it was much better than my experience with the initial installation of TFS 2008. Other IT pros have reported that you have to make changes to your MSBuild stuff, but since we have not integrated that with TFS, we did not have that issue. Our custom Work Item templates worked just fine, which made me really happy since I had put a lot of work into them.
If I were to do it again (including the initial TFS 2008 install), I would done two things differently:
- Have the TFS SQL Server be a separate instance, so it can be upgraded independently of other applications.
- Built a fresh Windows server for TFS 2010. I hoped to not have to reconfigure clients by reusing the machine, but I had to do it anyway in most cases.
The smartest thing I did was putting this on virtualized servers when I built it out the first time around two years ago. Being able to revert to a VM snapshot (as opposed to performing a full restore) gave me the confidence to do certain things and see if they worked. This was especially important when I was trying to fix the SSRS issues, where I found myself going back to the snapshot a few times.
If you are using TFS 2008, you can upgrade to TFS 2010 with confidence, as long as you are prepared to possibly troubleshoot SQL Server Reporting Services issues.
J.JaDisclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.
Justin James is the Lead Architect for Conigent.