How to move team services backlog work items to another tenant - azure-devops

I would like to move the backlog items and any related linked items to another tenant, any ideas?

There's nothing built in that does this.
You'll either have to write your own solution or look into one of the various migration or integration tools that are available on the market. None of them provide full fidelity migration, however.

As Daniel said that there isn’t built-in tool.
You can build an application with REST API to create the new workitems per to the workitems in another VSTS. Regarding Work Item creating REST API, there is bypass rules that can remain System.CreatedDate and System.CreatedBy value: Make an update bypassing rules.
On the other hand, there is 3rd tool: OpsHub Visual Studio Online Migration Utility

Related

How to upgrade a Team project to use the Inheritance model

We are using Azure Devops Server 2020 and have a project using the XML process model. The project belongs to an old collection which do not support the Inheritance model. When reading the article below I get the feeling it's possible to upgrade to use the Inheritance model. But my options in the administration UI are not the same as in the article. I guess it's because the collection itself does not support the inheritance model. Therefore I have created a new collection which supports the Inheritance model and wonder if there is a way to move my project to the new collection? Or is there any other way to upgrade my project to use the Inheritance model? The UI for the new collection does by the way look like the UI in the article.
https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/upgrade-hosted-to-inherited?view=azure-devops
I am afraid that this feature: Clone a Hosted XML process to an Inheritance process cannot be implemented in azure devops server.
According to the doc, this feature only exists in the Azure Devops Service. When you select azure devops server 2020 in the drop-down box in the upper left corner, you can directly see that it is not supported.
Here is a suggestion ticket about this feature. Our product group has decided not to implement this feature on azure devops server.
For those customers who wish to go to Inherited, you have the
following choices.
Move to the Azure DevOps Service
Create a new inherited collection and continue your project work
within that collection
On the other hand, you cannot directly move the team project to Inheritance Process Collection.
Azure Devops also does not support the movement of team projects between collections.
Here is a suggestion ticket about this feature: make it possible to move a Team Project between Team Project Collections
So if you want to create a new inherited collection and continue your project work within that collection, you could try to use the third party tools to migrate content of the project to new collection. For example:
Migration Tools for Azure DevOps
WIMigrator
This can get complicated. But you could refer to this ticket:
Currently there is no way to convert from XML to inherited on Azure DevOps Server (on-prem). Or next step is going to be able to allow mixed mode collections. Then figure out the right migration path from XML to Inherited. We are expecting to have mixed mode available some time on the Azure DevOps Server 2020 release. Probably update 1 or 2.
It seems that the mixed mode process can meet your needs. But this function has not yet been implemented,you may still need to wait for the implementation of this feature.

Closed - Duplicate a customized work item to be rehused for others work items Azure DevOps

Enviroment:
Azure DevOps
Action required:
To duplicated a custom Work Item to be rehused for others that requires that exact same lyout
Detailed description:
For a new Team Project is required a very specific setup, that was not easy to anchieve and needs to be replicated across all the rest of Work Item types like User Stories, Tasks, Fetures and so on and it would consume to much time do it manually (we are system engineer so there is always a better way ;) ) so for that reason is required duplicate the Taylored work item
I am afraid there is not such a feature to duplicate a custom work item tpye in azure devops currently. You may have to manually duplicate the work item types.
You can click here to submit a feature request to microsoft development team. Hope they will consider implementing this feature in the feature sprint.

Is there a way to create an organization dashboard in Azure DevOps?

Our team is currently using DevOps and are very pleased with how everything is working. We've setup Dashboards in each project that tracks work items and sprints and would like to do the same at the Organization Level. Is there a way to create a master overview of multiple projects in an organization?
Unfortunately we cannot create an organization level dashboard, it's not supported.
We can only create the Team Project level dashboards for teams, please see Add and manage dashboards for details.
However there's already a user voice submitted here to suggest the feature and it's in planned, but based on the response seems no plans to store a dashboard on organization overview. So you can vote it up and add your comments on the existing user voice or submit a new one to suggest the feature...
In our VSTS Feature
Timeline(https://learn.microsoft.com/en-us/vsts/release-notes/), you
see a feature called “Dashboards – Create dashboard separate from a
team” under “Reporting”
This feature will allow you to create a Dashboard that has no
association with the team. This means you don’t need to create a team,
to make a Dashboard. You can create any number of these Dashboards and
share them with who you want.
However, Dashboards will still be stored with a Team Project. So to
address your scenario (cross-team-project Dashboard), you’ll just have
to pick a team project to store the dashboard.
We don’t have immediate plans to store a dashboard outside a team
project.
Our team was dealing with the same problem as yours, and we decided to develop our own dashboard solution at the end.
After using it as an internal tool for several months, we recently made it available as a SaaS.
You may check it out on meercode.io for more information.
Your feedback will be greatly appreciated.
Behind the dashboard widgets are queries, and it is possible to execute those queries across multiple projects.
When you open the query editor, there is a checkbox:
"Query across projects" checkbox (imgur)
This way we created a project in Devops that only contains a dashboard that shows all work items in any project, assigned to or followed by the current user.
That and some nifty colored tiles =)

VSTS Workitem Tracking History Architecture

I need to create a history solution for a custom application and I'am curious how VSTS has resolved this problem in the workitem tracking histroy. I want to create something similar. Does anyone has informations about this architecture or db structure or is there some public documentation about the solution?
You should use Reporting Work Item Revisions REST API and then analysis for these data.
Besides, if you want to analysis for a certain work item, you can refer the REST API List Revisions.
And for relate example code, you can refer below links separately:
Example project for consuming the VSTS WIT Reporting APIs
Work item tracking revisions sample

Organizing Microsoft Azure DevOps Projects

I have a question about Microsoft DevOps (formerly Visual Studio Team Services or VSTS). I have multiple applications that are set up as separate projects, but we have basically one team of devs. Some of the older projects are TFS based some are git.
Ideally I would like to create a board based on the team and 'attach' projects to the board. Or something that ends up being roughly the equivalent of this.
I can't seem to find anything close to this. Does anyone have any ideas? Or any suggestions?
Thanks for your help!
As I mentioned in my comment you can use the AzureDevOps Rest API.
Representational State Transfer (REST) APIs are service endpoints that
support sets of HTTP operations (methods), which provide create,
retrieve, update, or delete access to the service's resources
Most REST APIs are accessible through our client
libraries,
which can be used to greatly simplify your client code.
Once you created your own board, you can fill up the details using the REST API response.