How can we improve Team Services?

make it possible to move a Team Project between Team Project Collections

Currently you need to move an existing Team Project to a new Team Project Collection. I would like a feature to move Team Project between Team Project Collections without using TFS Integration Toolkit or other 3rd party tools.

3,538 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Visual Studio ALM TeamVisual Studio ALM Team shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    Enabling the ability to move projects between collections is a feature that we’re committed to delivering. Since this feature is so highly requested, I’d like to provide some additional details behind why this has been pushed out.

    Simply put the issue is the cost to complete this feature. One way to think of it is that it’s XXXL in T-shirt sizing. A Team Project Collection (TPC) is a pretty rigid bounding container. It‘s the scope at which a number of “global” things exist.

    One such example is change set numbers. They start at 1 and count up in each TPC. That means projects in a TPC can’t have overlapping change set numbers. It also means that if you wanted to move TFVC projects between TPCs, you have to renumber all the change sets. That’s exacerbated by a requirement that change set numbers be time ordered. That means that the date/time associated with change set N must be before the date/time associated with change set N+1. Effectively meaning that you have to renumber all change sets both in the project being moved and in the target TPC. This is compounded by the number places that reference change set numbers. You can’t update them all, so you will end up with broken change set links.

    That’s just 1 of half a dozen complicated issues with moving projects between collections. When we designed the system we just didn’t think people would want to do that. A design choice that has long term ramifications.

    About two years ago we started an effort to take a different approach – moving the isolation boundary from Team Project Collection to Team Project. Meaning, for example, that each Team Project has its own change set counter. That design has some ramifications – like you can’t do a “tf get” across multiple projects at the same time and you would have to qualify change set numbers as “project:number”, but we felt that was a better trade-off. Again, there are related issues with work items and other artifacts.

    Unfortunately, we were not able to finish that work in time for TFS 2015 and then other work pushed it onto the back burner. There’s significant work (many months) left to complete it and then there’s working customers through the semantic breaking changes. We would still like to finish it at some point, but we don’t foresee us working on this in the next 6 months. That does mean that it won’t make our next major TFS version.

    We still plan to evaluate picking this work up and possibly getting it into the following next major release. We’ll provide an update once a decision has been reached.

    Rogan Ferguson
    TFS & VSTS Program Manager

    65 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  ·   ·  Flag as inappropriate

        This idea was originally posted July 14, 2011...by my count that's 6 years ago. Has any, ANY progress been made? If not, fine, will this functionality, moving Team Projects across TPCs, which honestly really should exist and why it can't is just excuses and highlights poor architectural designs, exist in 6 years from now?

        I don't care that it's XXXL and that it "costs" a million billion bajillion dollars....MSDN Enterprise subscriptions cost a million billion bajillion dollars when we have 100+ developers.

        The conversation on Brian's blog is richer on this topic...
        https://blogs.msdn.microsoft.com/bharry/2017/03/06/team-servicestfs-roadmap-update/

        Please Rogan before you post the next update here on uservoice about the "we are listening"...could you take the time to write up a way more detailed plan of how you concretely plan on fixing the "half a dozen complicated issues with moving projects between collections".

        We've been waiting 6 years...surely you can take 6 months and put together 6 detailed blog posts about how and what the engineering team will do to make this a reality.

      • Code ChiefCode Chief commented  ·   ·  Flag as inappropriate

        Sounds like an inherent design issue with the source and work item entities. Why should it be so complex to export or move these things around? Whatever the "ah but..." things are, they are clearly not fit for the purpose and holding everything back. Code change artefacts are essentially just some text or file changes at a certain date (of course more, but to simplify), some linked to work "records" (Product Backlog, Task, Bug, whatever according to template). Give everything a GUID and follow an XML schema, then it's portable. Include some logical "traits" which would enable it to be resolved when imported to a "foreign" system/location. As the end user, we work with names, locations, collections. An even if the whole work item stuff was too complex to think about, at least give us the possibility to move the source "safe".

      • Anonymous commented  ·   ·  Flag as inappropriate

        Makes total sense. That is a huge ask (crossing the TPC boundry).
        Anyone that has used TFS for any period of time in a significant way, or has designed software platforms, knows that at some point you have to have boundries or foundations to work against.
        Moving those later is tough. XXXL is a spot on!

      • Anonymous commented  ·   ·  Flag as inappropriate

        This is the #2 top idea having >3000 votes and its almost 6 years old and all we get is MSFT has "other things to do". Why is the ability to move projects between collections not considered part of "devops workflows"? This feature is needed especially for devops approaches.

        I really appreciate the new open culture MSFT is trying to establish. Many devs I know do not participate in uservoice anymore, because "its useless, no one cares". Please don't make me think the same way.

      • Carrie KistnerCarrie Kistner commented  ·   ·  Flag as inappropriate

        My company also really needs this feature and would like it to be in an update for TFS 2015 or at least for there to be some kind of tool provided that is supported, unlike the old TFS Integration Platform.

      • Randy in MarinRandy in Marin commented  ·   ·  Flag as inappropriate

        Darn, it appears that I will be retired before this feature is implemented. Perhaps all of us will be.

      • Rich WoodsRich Woods commented  ·   ·  Flag as inappropriate

        I know that moving Team Project between collections is NOT available in TFS 2017 RTM. Are we going to have to wait for TFS VNext (the next MAJOR TFS release) for this feature to be delivered or is it going to be possible in the next series of update releases to TFS 2017? I ask because we are running on TFS 2015 Update 3 and don't have any plans to upgrade to TFS 2017 in our production stack at this time. This ONE feature would make a compelling case and reason to upgrade to a newer version of TFS..and if it's going to be further off into the future that's fine...be stakeholders are asking if we should upgrade to TFS 2017..or just skip it and wait for the next MAJOR release train.

        Last question, will we be able to move EVERYTHING that is related to a team project (security groups, Collection level permissions, Build Server settings, Lab Management settings, etc)?

      • ÅkeÅke commented  ·   ·  Flag as inappropriate

        We are also looking forward to such a feature. Is it planned for an upgrade in TFS2017?

      • Anonymous commented  ·   ·  Flag as inappropriate

        Please provide this functionality. It creates a great degree of pain to your government customers when we go through realignment of divisions.

      • JC_NVJC_NV commented  ·   ·  Flag as inappropriate

        This would be a welcome feature. Since we are *very* close to 2017 at this point, any update as promised?

      • D-brosd99D-brosd99 commented  ·   ·  Flag as inappropriate

        I dont even understand how MS managed to sell the product without out some of the basic features.

        Shame

        And what is even more interesting is that companies have bought this.

      • Vincent ChowVincent Chow commented  ·   ·  Flag as inappropriate

        This is a major pain point for managing active team projects and archiving old ones. This feature should have been available since... yesterday may be?

      • Ralph SchindewolfRalph Schindewolf commented  ·   ·  Flag as inappropriate

        Please provide a way to archive collections or at least seamless archive team projects and move them to collections that can be archived. Really looking forward to this feature as we have team projects scattered over numerous TFS instances in different collections and we'd love to be able to consolidate down to one team project collections. 2017 can't get here fast enough for this feature.

      ← Previous 1 3 4

      Feedback and Knowledge Base