How long is my TFS 2010 to 2013 upgrade going to take?

I seem to be involved with a number of TFS 2010 to 2013 upgrades at present. I suppose people are looking at TFS 2013 in the same way as they have historically looked at the first service pack for a product i.e: the time to upgrade when most of the main issues are addressed. That said TFS 2013 is not TFS 2012 SP1!

A common question is how long will the process take to upgrade each Team Project Collection? The answer is that it depends, a good consultants answer. Factors include the number of work items, size of the code base, number of changesets, volume of test results and the list goes on.  The best I have been able to come up with is to record some timings of previous upgrades and use this data to make an educated guess. 

In an upgrade of a TPC from TFS 2010 to 2013 there are 793 steps to be taken. Not all these take the same length of time, some are very slow as can be seen in the chart. I have plotted the points where the upgrade seems to pause the longest. These are mostly towards the start of the process where I assume the main  DB schema changes are being made


To give some more context

  • Server A was a production quality multi tier setup and took about 3 hours to complete.
  • Server B, though with a a similar sized DB to Server A, was much slower to upgrade, around 9 hours. However, it was on a slower single tier test VM and also had a lot of historic test data attachments (70%+ of the DB contents)
  • Server C was my demo/test TFS 2010 VM, this had 4 TPCs, the timing are for the largest of 600Mb. In reality this server had little ‘real’ data. It is also interesting to note that though there were four TPCs the upgrade did three in parallel and when the first finished started the fourth. Worth remembering if you are planning an upgrade of many TPCs.

Given this chart, if you know how long it takes to get to Step 30 of 793 you can get an idea of which of these lines closest matches your system.

I will continue to update this post as I get more sample data, hope it will be of use to others to gauge how only upgrades may take, but remember your mileage may vary.

Upgrading our TFS 2012 server to 2013

We have eventually got around to the 2013 upgrade of our production TFS server. It had been put off due to some tight delivery deadlines around Christmas.

The upgrade went fine, unlike out some previous ones we have had.

The upgrading of our team process templates, to add the new features, was greatly eased by using Feature4Tfs tool on CodePlex. This meant one command line call and all the projects were done (we had no significant process customisation) as opposed to visiting in team project in the admin console.

For now we are continuing to run with our TFS 2012 generation build and test controllers. These are working fine with 2013, so we can upgrade these when it is convenient, not all in a rush.

Changing targeted .NET version for a project means web.config changes for EF

I am upgrade an internal system from .NET 4.0 to 4.5 so that I can use the Team API features in TFS. The system is based around a WCF web service that links our customer help desk system to TFS to keep bug reports in sync. It uses Entity Framework to access our help desk SQL DB.

When I changed the targeted .NET framework  for the WCF project, I started to get warning to update the Nuget managed references for EF, which I did.

Once this was done, all my unit tests passed, however when i tried to load my test system it got the following  error (when it tried to create the EF DbContext)

An exception of type ‘System.TypeInitializationException’ occurred in EntityFramework.dll but was not handled in user code

Additional information: The type initializer for ‘System.Data.Entity.Internal.AppConfig’ threw an exception.

Turns out the issue was a reference to EF in the WCF project web.config

    <section name=”entityFramework” type=”System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089″ requirePermission=”false” />
    <!– For more information on Entity Framework configuration, visit –>

should have been

    <section name=”entityFramework” type=”System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089″ requirePermission=”false” />
    <!– For more information on Entity Framework configuration, visit –>


A misleading error message don’t you think?

Fix for intermittent connection problem in lab management – restart the test controller

Just had a problem with a TFS 2012 Lab Management deployment build. It was working this morning, deploying two web sites via MSDeploy and a DB via a DacPac, then running some CodedUI tests. However, when I tried a new deployment this afternoon it kept failing with the error:

The deployment task was aborted because there was a connection failure between the test controller and the test agent.


If you watched the build deployment via MTM you could see it start OK, then the agent went off line after a few seconds.

Turns out the solution was the old favourite, to reboot of the Build Controller. Would like to know why it was giving this intermittent problem though.

Great support from BlogEngine.NET

I posted yesterday that we had upgraded to the current version of BE 2.9. We, as you might expect, had a few minor issues, but I must say the support on the discussion forums has been excellent.

This included the problems I had that were down to missing files and web.config issues (basically my copy errors when moving content from our BE 2.8 instance to the new BE 2.9 on) and a genuine bug in the new CustomFields code (fixed in All discussion posts were responded to, and in the case of the bug fix, within a very short period of time.

If you need a blog server and have not looked at at BlogEngine.NET I think it will be well worth your time taking a peek

Upgrading from BlogEngine 2.8 to 2.9

I have just upgrade our Blog Server from BlogEngine.NET 2.8 to 2.9, all seems to have gone well, as before basically it is just copies files and adds s table to the DB schema, so…

  1. backup your blogs folder and SQL DB in case of problems
  2. delete the contents  of the blogs folder
  3. copy in the the new release from the zip
  4. run the SQL upgrade script on your DB
  5. fix the SQL connection string in the web.config
  6. copy in the theme and extension files you were using as detailed in the release notes, but I found using updater utility did a great job for me

As many of our sites were using the standard theme, it picked up the new bootstrap based version. Anyone with the other themes just see what they saw before