My development team presently uses the following software in our workflow:

  • JIRA
  • Bamboo (Atlassian continuous integration)
  • Greenhopper (Atlassian agile project management)
  • Confluence
  • Git, hosted on BitBucket
  • Visual Studio 2012

As you can see we are quite heavily invested in the Atlassian ecosystem. We are considering a move to TFS so we can get the niceties of advanced Visual Studio integrations such as code reviews and more importantly the Microsoft Test Manager.

My previous experience with TFS was with 2005 or 2008 (I can't remember) and I have bad memories of it, although not quite as bad as my time with ClearCase.

What criteria should we be looking at in order to properly evaluate our move to TFS?

  • 4
    I moved from a company on git to a company with TFS 2008 and it is incredibly painful. I hear 2012 is much nicer.. but we aren't in a position to upgrade at the moment. As it currently is though... I would kill to go back to git :( Commented Aug 16, 2013 at 8:30
  • 1
    That's correct. TFS 2008 was hard both to maintain and to use. But there is a strong positive tendency: TFS 2010 was much better then 2008, TFS 2012 is just as much better then 2010. It's much more maintainable and has great web interface so it can be used by people without Visual Studio (testers and product owners, etc) Commented Aug 16, 2013 at 9:21
  • @SimonWhitehead as someone who moved from TFS2008 to TFS2012, the differences at a fundamental user level aren't much changed - there's new bits round the edge (eg code reviews, scrum web page, etc) but you'd still hate it. Upgrading ... forget it, you need to do a clean install and copy your data in.
    – gbjbaanb
    Commented Aug 16, 2013 at 14:31
  • 4
    Even TFS 13 has nothing to compare with JIRA Agile. Their current "Kanban board" implementation is a pathetic attempt to bring life to this dead-born child. To replace Cofluence you will find nothing at all. I am not sure why anyone should consider moving from Atlassian stack to TFS stack. I am using TFS for many many years and I was never happy with it, neither my colleagues were. Commented Jan 27, 2014 at 13:58
  • 1
    As you're already invested in the Atlassian ecosysten, I'm surprised no-one has mentioned Atlassian Stash, which runs on top of Git and gives you features such as repository access management, pull requests, code reviews and automatic merging strategies. It's quite nice. Commented Mar 19, 2015 at 3:01

5 Answers 5


Martin Fowler's little survey says a lot about the state of TFS in previous years. 'dangerous' is quite right. (I think this refers to the way that it doesn't recognise changes made outside of VS, so you can create a WCF project, then use the external svcutil tool to create your client, then check all your changes in.. but TFS will happily ignore your client changes because they weren't made inside VS).

You have to count the cost : the required version of VS to get the goodies - code reviews, for example, require Premium edition which is significantly more expensive if you get VS via MSDN. Also, accessing the system for non-VS users is fine, but if they want the full access instead fo the cut-down web view, then you'll have to shell out for CALs for them. The overall cost of TFS can be quite a lot. Even the recent Forrester report (commissioned by Microsoft, so you have to read between the lines a little) says that TFS requires significant administration support - 2 consultants and 6 admins (who spent 25% of their time) were required to support TFS for their case study of 122 users (works out to 4.5 admins over those 122 users... this is a lot compared to just me setting up and maintaining a full SVN solution whilst also doing my day job). TFS can take a lot of effort to keep working as people expect.

In my experience with TFS2012 (forget previous versions as they're crap), is that is is a very complicated system administer, especially if you step outside the pre-defined setup. For example, if you use MSBuild to build everything, you're fine. But if you have, say, a load of old .vdproj propjects that are no longer supported by MSBuild, you have to edit the huge xaml build script to make it build these projects. After several days working on this, the best I could do was to rebuild the solution by passing it to devenv, and even then, getting the build results out and into the build summary was impossible. Similar results were had by other teams who used NUnit for their tests - if you use the built-in MSTest, then it works. Otherwise, you're pretty much stuffed.

As a user, I find that the integration is more of a nuisance. I prefer TortoiseSVN and I do nearly all of my SCM work via that (as it is an awesome tool). With TFS, you end up with a new screen inside VS for every operation. So you have a new tab in your environment for the team explorer, and another for the builds, and another for each build summary you want to see (and if you want to see the details of a build, an error for example, you have to click through too many links). I found the number of documents I had open when using TFS were more than the source files!

The same applies to checkins, committing changes required clicking through several tabs on the Pending Changes pane in VS to assign a work item and comment to your checkins. Its a small thing, but I found it annoying as I was used to more streamlined tools.

Extending the build system was another area that I found lacking. Adding new features into the build is difficult because of the xaml configuration, and getting the results of those features into your build screens is either very very hard, or impossible. So if you like adding stuff like code complexity or static analysis, or even automated testing via, say selenium, or deployments... forget it. Unless, you are using the Microsoft tools for these aspects (eg fxcop).

Updating the workflow was another niggle - though the powertoys helped tremendously, it was still awkward to get the workflow right,and you still can't configure the scrum board with the information you really want to see - again, you get the defaults or nothing.

Merging was also painful, I think there's a very good reason MS has adopted git for TFS (note this only works with brand new TFS projects, you cannot convert from TFS to git backends).

So all in all, its not too bad as it does work, but I have found a lot of other tools are much better. The disadvantage of those tools is that they don't come fully integrated, but IMHO this is a strength as you can pick and choose the best bits you want. With TFS you get pretty much what someone else wants you to have. If you decide the bug system in TFS is poor (and I think you will), you'll have a hard time changing to a different one.

TFS should be considered along with other big, fat full-lifecycle tools. Most developers hate such things as they dislike the restrictions these tools end up imposing on them.

I would try it though, download the 30-day trials and install it. When evaluating remember to change a little bit here and there, don't just use it for a source code checkin, checkin with a workitem required and get reports based on that workitem. Try assigning a checkin to multiple workitems, and try combining workitems together as related. Try to incorporate something different into the build system, see how to get a daily progress report out of the reporting services, link a document to a workflow requirement and trace it through bug triage to coding to build to rework and then release. Branch and merge a lot. If you can't easily do all these things, then you might as well stick to git. There's not much point to using TFS if you don't take advantage of most of its ALM features.

  • 1
    Thanks for sharing your experiences and its good to get some negatives. I used ClearCase a while ago in an enterprise and that was the worst SCM I have ever used. The administrative overhead is concerning, we're a small startup but I really love that our current setup requires practically no administration.
    – Sam
    Commented Aug 17, 2013 at 1:46
  • Serena Dimensions was the worst I ever used, Clearcase didn't seem nearly so bad in comparison, at least it worked! I think MS wants you to go with their cloud version of TFS, self-installed is something they can sell to corporates for big bucks. I'd stick with what you have. Get some more tools to give you the same functionality (eg ReviewBoard).
    – gbjbaanb
    Commented Aug 17, 2013 at 19:51
  • oh, and I know its a bug so its not really fair to highlight it - but if you try the code review feature of TFS, and you try to review a file that has been renamed as well as modified, TFS will report a "previous revision not found" error. If you do a lot of refactoring, this may be a problem. It might be a little bug, but then it might also be a major architectural problem if they don't track file renames in the TFS back-end store.
    – gbjbaanb
    Commented Aug 17, 2013 at 19:53
  • 2
    Sorry for the late reply, it was ultimately you who talked me out of using TFS. Thanks.
    – Sam
    Commented Aug 21, 2013 at 4:10
  • 1
    Good to hear it - everyone seems to think they must use TFS, when really we all should be using a wide range of tools. Otherwise we will end up with only 1 or 2 companies that provide all our IT tools... Microsoft and Oracle... that would not be the nicest world to live in :) Atlassian do good tools, more people should evaluate them.
    – gbjbaanb
    Commented Aug 21, 2013 at 10:44

I've moved from a company with a largely Atlassian stack (and Mercurial) to a company with a heavy TFS stack. I find two irritations.

The first is Source Control.

When you've got used to DVCS, switching back to a CVCS is painful. TFS is particularly painful because, for all that integration to work, it insists on being connected to the server at all times.

However, thankfully, Microsoft have recently allowed for integration of Git version control into the rest of the TFS stack. So you don't need to give up Git, and I advise you not to, given that everyone already knows it.

I'm not yet sure how well the code-review tool works against Git though, given that it seems to rely a lot on shelvesets (a little like stashes, but not so powerful). But then relying on shelvesets for code-review is painful in itself because it discourages regular commits.

The other irritation is the reason most people won't consider moving away from TFS: The Visual Studio Integration.

I have yet to figure out the cognitive reasoning behind this but, in my experience (and taking into account that this is generalising), people who are used to TFS love the integration. They don't like to move outside their IDE for anything.

I, on the other hand, have not warmed to it after a year. I find it cluttered and hard to navigate, compared to having my build server in one browser tab, my tickets in another browser tab and so on. (Edit: As Andrei notes, there is a web interface, but it is also inexplicably clunky, when you're used to more recent versions of Jira and Jenkins. But still, it does at least work in browsers other than IE now. So that's something.)

I never look at builds unless I'm trying to do one, and then I find it hard to find out if someone else is already doing one. I don't see other people's changes unless I'm asked to review.

But, your milage may vary. As I say, some people seem to find it indispensable. I just can't help noticing that it's generally people who have never done it another way.

Also, don't fail to notice that this is 2 negatives, one of which may be personal, in a pretty large infrastructure. Most of my experience is good and TFS isn't as bad as some people will have you believe. And most things you find you're missing can probably be switched on (it's very configurable); given that you're moving a whole team, rather than one person, you might find less resistance.

  • 1
    This is basically what I would have answered with. Glad to know I'm not the only one! Commented Aug 16, 2013 at 14:35
  • 1
    you can do code review of committed code, but you just know the fact that you can prevent checkins until after review means people will use it exactly like that. Corporate policies everywhere will be written so this is mandatory, and then it'll become another process bottleneck to piss developers off.
    – gbjbaanb
    Commented Aug 17, 2013 at 19:56

I have a very positive experience of using TFS 2012. It is quite easy to set your TFS server up and running, CI build automation is very simple and straightforward (and the Gated check-in build is just awesome. We failed to achieve same functionality with Team City). Team interaction is very transparent and straightforward too. You can easily associate your check ins to TFS workitems, manage a backlog, track defects, do codereviews and so on. There is even a messenger build in =)

However keep in mind that if you accustomed to your JIRA's workflow, setting up TFS workflow could be a tough task. I'd suggest adopting one of the predefined TFS workflow. Also you will have to keep Confluence as you knowledge base or switch to SharePoint as there is no wiki build into TFS.

TFS is much more cheaper if you have a MSDN subscription (I believe most developer companies working with MS technology stack have it) in that case you have TFS for free.

I think there is no reason to keep using side parties tools if you all your developers are working with Visual Studio. TFS provides integrated, robust yet easy to use ALM system. I will gladly answer your questions if you have any.

  • 1
    thanks very much for your feedback. We're using BizSpark which I am fairly certain has TFS included. I guess the only thing I'd like from you is any negatives, just to weigh it up. I'm happy to stay with Confluence as I really dislike SharePoint.
    – Sam
    Commented Aug 16, 2013 at 9:02
  • The change notification system in TFS is somewhat simpler the in other solutions (Test Track for example has much more robust system). In TFS you only get notifications if workitem is assigned to you, you can not subscribe to changes on specific workitem for example. I think its not a big problem in an agile work process, but if you rely heavily on notifications in your work process it may be a pain. Source control will require some time to get used to. Especially if you accustomed to GIT command-line commands. But the branching visualization is worth the efforts I think. Commented Aug 16, 2013 at 9:15

I thought it would be worthwhile updating this question with some thoughts from the end of 2021.

When I asked this question almost a decade ago, Git was nowhere near as widespread as it is today and if I remember correctly there was minimal integration in Visual Studio.

I started a job in mid 2014 that was heavily invested in the Microsoft ecosystem, including TFS. TFS proved to be a pain for multiple reasons:

  • Workspaces are a complex solution for a simple problem
  • Exclusive locking is a pain
  • Requiring connectivity is likewise a pain, if the WAN drops or the server goes down, you can't check a file out to edit
  • Resolving disconnected changes is a manual process
  • Branches are a heavy-weight object and generally long lived
  • The permission system is great for an Enterprise with 100k+ employees but makes little sense for a small to medium sense shop
  • Code reviews, at least in the version we're using are painful and we usually resort to putting review comments in the code
  • Merging is incredibly painful. Nothing like Git.

We've been moving new development to Git, initially with Azure DevOps and also Github. I find the PR management on DevOps to be a better experience than Github, but both are leagues ahead of TFS.

TLDR Comparing TFS to Git (which is absolutely the choice to make in 2021) is like comparing XML/SOAP to JSON/HTTP. TFS has some pretty powerful features but given Microsoft never widely adopted it (stuck with Perforce before moving to Git) should tell you all you need to know.

  • "Requiring connectivity is likewise a pain ... you can't check a file out" - strange objection, since "checking out" by definition involves marking the central copy of the file as checked out by a specific user. I agree with the conclusion though - TFS is a very heavyweight, enterprise-oriented system, if not a downright spruce goose.
    – Steve
    Commented Oct 20, 2022 at 9:21

Peoples should know, TFS is not just VCS, it is ALM.

Seem many peoples just want a VCS but go for TFS is wrong way.
For CVCS, I still prefer SVN.
For solo or open source, sure go for GIT.

But TFS2012 is not bad, it is easy understand on merge/fork then SVN.
And team foundation service is free for 5 user / unlimited,private repo.

Client is free too, TFS explorer build on top of VS2010 and it is free.
For Eclipse, it has Eclipse plugin - TFS everywhere.

I don't see any cost problem on that.
TFS express (free) can be work with SQL Server Express (free too).

  • 1
    how does this answer the question asked?
    – gnat
    Commented Sep 2, 2013 at 12:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.