I have a TFS2018 on-premise and Azure DevOps Server on-premise with many collections, and my goal is to migrate workitem from one collection to another within each server.
" You can only move work items from one project to another project within the organization or collection . " - said https://learn.microsoft.com/ru-ru/azure/devops/boards/backlogs/remove-delete-work-items?view=azure-devops&tabs=browser#move-a-work-item-to-another-project .
What does it mean within the organization ? From one collection to another? :)
So is it really possible?
Thanks in advance
within the organization or collection - its just within Azure DevOps Organization (old VSTS) and Azure DevOps Server (or TFS) Collection. Organization = Collection. We can not move a work item into another collection or organization.
TFS/Azure DevOps Server include three level, sever level--collection level--team project level
Azure DevOps Service include two level organization(equal to default collection)level--team project level
It's not able to migrate WIT from one collection to another in TFS server.
Another evidence to prove is work item ID, it's unique in a single team project collection.
Work Item ID
The unique identifier that is assigned to a work item. Work item IDs
are unique across all team projects and within a team project
collection. Reference name=System.Id, Data type=Integer
If you are able to migrate across team project collection, how would you handle a work item with same ID in different collection.
Actually this ID is stored in TFS database and have various purposes such as work item query, TFS API and so on. Each collection has it own's database.
You cannot move items from collection to collection, you'll need to export them to excel and then remap to the new collection/Azure DevOps Account and publish them, like Patrick mentioned those items will not have the same number they will be created with a new number. There are others ways to do this, you can use the REST api and write some .NET or PowerShell code, or you can try and use Martin's migration tool (https://marketplace.visualstudio.com/items?itemName=nkdagility.vsts-sync-migration).
Related
I am trying to import a work Item from TFS to Azure and I want all the link types associated with the work Item to be imported in Azure. we have lot of custom fields and links in TFS. What can I do if the link type exists in TFS but does not exist in Azure. Can I do any mapping like how we do for field mappings.
For example in TFS , I have a User story implements (link type) a spec but in Azure I want to use User story references (link type) a spec.
So when I am importing a user story with specs linked to it and link type 'implement' it should convert it to 'references' when it imports. Is it possible?
You'll need to use the Azure DevOps Migration Tools, and create a mapping configuration specifying the from/to of work item types, fields and relations.
You'll probably need to build a WorkItemLinkEnricher to map from one link type to another.
You could also do an as-is import of the project collection and leave it in XML mode, that way the existing links will migrate over, but you won't have all the advantages of the new Process Model in Azure DevOps.
I have a question.
Lets say I have 3+ projects in TFS
For example
Microservice A
Microservice B
Microservice C
And now my company sign 2 contracts. With Company ABC and Company ZYX.
Now Project Manager want to open tasks for 2 projects - Company ABC and Company ZYX.
But those tasks associated with ALL MICROSERVICE .
That is mean he is need to open tasks in each projects in TFS.
Question is:
If he able to see what is status of projects (where projects is project with Company ABC and Company ZYX.)
P.S - Integration with Project Server is not good. Looking for something else (better inside TFS )
You could create a task in every team project that has work to be done and use tags in tasks, user stories, etc to track for which customer it is for.
Create a custom cross project query to get all you workitems.
You could filter by tag or list all tasks and put the tag as a column.
It's not suggested use one team project for two companies. For enterprise-level organizations, it may be necessary to scale up, to create additional teams and/or team projects. These can be created within the single account or collection. Please check the following link:
https://learn.microsoft.com/en-us/vsts/work/scale/scale-teams?view=vsts
We have a TFS 2013 on-premises server that we just migrated over from VSO for a customer. They originally had 2 VSO accounts. Each account had a collection of projects. They have now been attached to the TFS thereby creating 2 collections that we can see & browse successfully. They'd like to merge all of the projects into one collection while maintaining all history info, etc... Is this possible? We are NOT trying to merge projects...ONLY the collections.
The process for merging Collections is exactly the same as the process for merging Team Projects. You would pick one collection to keep and create a new Team Project for each of the Team Project that you want to migrate from the other collection. You would then use the TFS Integration Platform to push the data across...
I know this is not what you want to hear but it is the only possible way to achieve this.
I have a TFS 2010 Work Item Type with a custom field called "Requested By." This field can be populated with any name, but since most of the requests come from project developers throughout the organization, the SUGGESTEDVALUES property should populate the dropdown list with members of any TFS team project.
I have tried various values for SUGGESTEDVALUES, but both Collection\ Project Collection Valid Users and Server\ Team Foundation Valid Users seem to return every valid Active Directory account—well over 10,000 names.
I recognize that one option is to add an ALLOWEDVALUES item with multiple LISTITEM entries for Project\ Contributors for every team project, but with more than 150 team projects in the organization, this would be time-consuming initially and challenging to manage in the future.
Is there any easy way to populate the drop-down with TFS valid users who have actually been assigned to any team project in the collection, and exclude "Valid" users who exist in Active Directory but have never been assigned to a project?
What do you get if you use Project Collection Valid Users?
Project Collection Valid Users is the correct group to use, and I have entered it correctly.
However, one project team wanted to make their code available to the entire organization, and added ORG\Domain Users to the [Project]\Readers group. This was discovered by running a full audit with TFS Projects based on a hunch that something like that must have happened.
Having answered this question with "because a project team was doin' it wrong," I have posted a follow-up question to find out how to correctly grant all valid TFS users access to a specific project. See How can I grant Team Project access to all Project Collection Users? for the discussion on (hopefully) doing this "the right way."
I'm considering storing the URI for a workitem from our TFS environment in our helpdesk system, however looking at the URIs TFS gives us (vstfs:///WorkItemTracking/WorkItem/327), there doesn't appear any recognition of which team project it is associated with, which makes me wonder how meaningful they are?
Is it possible to load a workitem by just URI? Or will I have to store the Project URI as well?
The work item URI is unique across the Team Foundation Server in TFS 2008/2005 or across the entire Project Collection in TFS 2010 (TFS 2010 has a new notion of project collections - see here for more information). The Team Project that it is in does not affect the ID.
Therefore to have a unique reference to the work item so that you'll always be able to get to it in the future you need a TFS server URI and a Work Item URI (i.e. http://tfsserver:8080/ + vstfs:///WorkItemTracking/WorkItem/327)
If you will only ever have a single TFS server or a single TFS project collection in TFS 2010 that your CRM system is attached to then you can assume all work items are linked to a single TFS Url.
The URI is meaningful since the item number at the end of the URI is unique and links to the item in TFS. I think storing this URI in another system makes sense considering the fact that it contains the identifier of the item.