Bulk move work items and change the work item type in Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Sometimes, work items get created with the wrong type or assigned to an incorrect project. You can correct these issues by updating individual work items or bulk modifying multiple items. You can also remove irrelevant work items from your backlog or Taskboard.
To change the type of multiple work items, export them using Excel and reimport them with the correct type.
In the web portal, multi-select work items from a backlog or query results page to perform bulk updates. To change, move, delete, or restore multiple work items simultaneously, see Bulk modify work items.Often you find that someone created a work item of the wrong work item type (WIT) or within an incorrect project. You can correct these issues for individual work items or bulk modify several work items. You can also remove work items added to your backlog or Taskboard that aren't relevant anymore.
For instructions on removing, deleting, or restoring work items, see Remove, delete, or restore work items.
Prerequisites
- Permissions:
- Be a member of the Contributors or Project Administrators group. To get added, Add users to a project or team.
- To modify work items, have your View work items in this node and Edit work items in this node permissions set to Allow. By default, the Contributors group has this permission set. For more information, see Set permissions and access for work tracking.
- To move work items to another project, be a member of the Project Administrators group or have the Move work items out of this project permission set to Allow. By default, the Contributors group doesn't have this permission set. Users with Stakeholder access don't have access to this feature.
- Access levels: To change the work item type, have at least Stakeholder access.
Note
Users with Stakeholder access for a public project have full access to all work tracking features just like users with Basic access. For more information, see Stakeholder access quick reference.
- Permissions:
- Be a member of the Contributors or Project Administrators group. To get added, Add users to a project or team.
- To modify work items, have your View work items in this node and Edit work items in this node permissions set to Allow. By default, the Contributors group has this permission set. For more information, see Set permissions and access for work tracking.
- To move work items to another project, be a member of the Project Administrators group or have the Move work items out of this project permission set to Allow. By default, the Contributors group doesn't have this permission set. Users with Stakeholder access don't have access to this feature. Also, the project must use an Inherited process model.
- Access levels: To change the work item type, have at least Stakeholder access.
You can change the work item type or move work items to another project within a project collection. These features require that the data warehouse is disabled. With the data warehouse disabled, you use the Analytics Service to support your reporting needs. For more information about disabling the data warehouse, see Disable the data warehouse and cube.
For more information, see Change project-level permissions.
Important
You can't change type or move work items whose work item types support test management or that belong to the Hidden Types Category. This includes all work items that track tests—such as test cases, shared steps, and shared parameters—code review requests and responses, and feedback requests and responses.
Important
You can't change type, move work items, or delete/restore work items whose work item types support test management or that belong to the Hidden Types Category. This includes all work items that track tests—such as test cases, shared steps, and shared parameters—code review requests and responses, and feedback requests and responses.
You can't change the work item type if the project is defined on a collection that uses the On-premises XML process model.
Change the work item type
Changing the work item type refreshes the work item form with the fields defined for the type selected. For example, you can change a bug to a task and the form refreshes with the fields defined for a task.
You can change a single work item or several multi-selected work items to a new type.
Open a work item, choose the actions icon, and select the Change type... option.
Or, from the backlog or query results page, multi-select several work items whose type you want to change. You can select several work items of the same type or different type so long as you want to change them all to the same work item type.
Choose the actions icon, and select the Change type... option.
Important
From the Query Results page, the Change type… option becomes unavailable if you have checked the Query Editor's Query across projects checkbox.
Select the type and optionally enter a comment.
Comments are automatically added to the Discussion and an entry gets made to the History. Also, the system automatically resets the State and Reason fields to the default initial values for the work item type that you move.
Save the work items.
Note
The system automatically resets the State and Reason fields to the default initial values of the specified type. However, in some cases you may need to open the work item to change the State or Reason field to a value supported by the changed-to work item type.
From the Query Results page, save all work items that you bulk-modified. When you bulk modify items from the backlog, they're automatically saved. Work items shown in bold text indicate that local changes aren't saved to the data store. The system automatically saves each work item. To reflect your changes, refresh.
Move a work item to another project
When you realize that a work item is assigned to the wrong project within your organization or collection, you can move it to the appropriate project. You can relocate either a single work item or multiple selected work items.
Important
Permanent and irreversible deletion: Azure DevOps only supports the permanent deletion of test artifacts, including test plans, test suites, test cases, shared steps, and shared parameters. Deleted artifacts cannot be restored, and all associated child items, such as test results, are also removed. Additionally, bulk deletion of test artifacts is not supported; attempting to bulk delete will result in the deletion of all other selected work items except the test artifacts.
Ensure you back up any necessary information before deleting test artifacts, as this action can't be undone.
Open the work item and choose the Move... option from the work item form's Actions menu.
If you don't see the option, then you don't have permissions to move work items out of the project.
Or, from the backlog or query results page, multi-select several work items that you want to move to another project. You can select several work items so long as you want to move them all to the same project.
Choose the actions icon to open the context menu of one of the selected work items, and choose the Move… option.
Select the destination project and choose the other options available, including changing the work item type. Optionally enter a comment.
Note
Child work items don't get moved and remain in the origin project, but the Parent-Child links remain in place.
Comments are automatically added to the Discussion and an entry gets made to the History. Also, the system automatically resets the State and Reason fields to the default initial values for the work item type that you move.