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.
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.
TFS & VSTS Program Manager
Rogan, Has the team made any progress with this feature request? If so, can you share a revised plan illustrating when the feature may be available? I'm working with several teams that had created 12 isolated VSTS instances, and have been tasked with consolidating these multiple instances back into 1. Thanks. -Brendan
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...
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 Chief commented
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".
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!
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.
This feature is needed when divesting companies.
Carrie Kistner commented
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.
Eric J. commented
great news, thank for feedback Rogan :)
Randy in Marin commented
Darn, it appears that I will be retired before this feature is implemented. Perhaps all of us will be.
Rich Woods commented
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)?
We are also looking forward to such a feature. Is it planned for an upgrade in TFS2017?
Please give us an update
Bruce Gilstrap commented
One more vote in favor of this feature
Samuel Veiga commented
would like this feature as well.
Please provide this functionality. It creates a great degree of pain to your government customers when we go through realignment of divisions.
This would be a welcome feature. Since we are *very* close to 2017 at this point, any update as promised?
I dont even understand how MS managed to sell the product without out some of the basic features.
And what is even more interesting is that companies have bought this.
Do you have some update about the timeline for this?
Moving Team projects or even the code with history between projects/collections would definitely stop people suffering from the pain. You need to see how hard those guys worked just to make a workaround - building single huge TFS project, just like put all files in the root directory without using folders.
Vincent Chow commented
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?