Even though there is talk of TFS 2013, with the first CTP due towards the end of June, I’m still doing quite a few upgrades to TFS 2012 at the moment.
When considering upgrading to TFS 2012, there is basically one of two approaches, namely an in place upgrade or a migration.
The in place upgrade is probably a bit less “complex”, even though it can be quite involved. You need to get the environment to a TFS 2012 friendly state (note those service packs!) and then do the upgrade which can take some time.
I highly recommend doing a test upgrade first, work out and document all the kinks before you shut down and attempt a production upgrade.
The test will give you an indication of what can happen before you start, and how long the upgrade will actually take.
With an in place upgrade there is not much you can do to reduce the amount of time that the upgrade will take, you would need to go through all the steps, which will involve uninstalling TFS 2010 and installing TFS 2012 and then upgrading the databases.
You do gain some time in that you would not need to change the SharePoint or reporting services links.
Personally I prefer doing a migration as apposed to the in place upgrade. This means that I can spend the time and configure a new “fresh” environment, then take a TFS 2010 database across and make sure everything works. Any problems can be sorted out in the new environment and you most probably won’t need to keep an extensive log to remind yourself of the problems during the actual upgrade.
On D-Day you just need to take over the TFS 2010 database, and do the post configuration steps. This will also retain the TFS 2010 environment in case anything goes wrong.
Some things that you need to take note of with the migration are:
1) Rebind SharePoint
Have you opened up the project’s SharePoint portal and it has red block strewn all over it?
I have found that “Repair Connection” will in most cases sort out the links adequately. If however you have not stuck to the default SharePoint sites or you use sites that are located on different servers, you would need to manually “correct” these bindings.
Open up Visual Studio, go to Team explorer Settings and open up the “Portal Settings”.
Re-establishing the connection here works as a last resort (for example uncheck the “Reports and dashboards…” checkbox , click OK , open it back up and then select it, click OK again ) .
2) Reporting Services
If you are considering moving SSRS there are a couple of steps that you need to take into consideration:
- Restore both the ReportServer and ReportServerTempDB on the target server
- Make a backup of the SSRS encryption key from the source server and then restore it on the target server
- In Reporting Services Configuration Manager, make sure that only the target server is in the “Scale-Out Deployment” section. If the old server is still there, remove it.
- If it won’t simply remove by selecting it and clicking “Remove Server”, then open up the ReportServer database and remove it from the Keys table
- Make sure that the top level security ( in http://<report server>/Reports ) is set adequately
- Make sure that your TFS data sources ( “Tfs2010OlapReportDS” and “Tfs2010ReportDS”) points to the correct server
- And finally, in the TFS Admin console, make sure that on the Reporting view, you are pointing to the correct SSRS server
3) Build Template
Make sure that your build templates have been updated correctly and any custom activities are referencing the new TFS 2012 assemblies.
Upgrade the project templates from TFS web access admin site and setup the team members.
Depending on the hardware that you are doing the upgrade on a 15GB TFS database can take 40 minutes to an hour and a 45GB database can take in the vicinity of 3 hours.
If you are looking to upgrade TFS to TFS 2012, feel free to give us a shout