Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
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.
Tip
You can use AI to help with this task later in this article, or see Enable AI assistance with Azure DevOps MCP Server to get started.
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
| Category | Requirements |
|---|---|
| Permissions | - Member of the Contributors or Project Administrators group. To get added, Add users to a project or team. - To modify work items: 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. For more information, see Set permissions and access for work tracking. - To move work items to another project: Member of the Project Administrators group or Move work items out of this project permission set to Allow. By default, the Contributors group doesn't have this permission. Users with Stakeholder access don't have access to this feature. |
| Access levels | To change the work item type: 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.
| Category | Requirements |
|---|---|
| Permissions | - Member of the Contributors or Project Administrators group. To get added, Add users to a project or team. - To modify work items: 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. For more information, see Set permissions and access for work tracking. - To move work items to another project: Member of the Project Administrators group or Move work items out of this project permission set to Allow. By default, the Contributors group doesn't have this permission. 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: 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, delete, or restore work items when the work item types support test management or belong to the Hidden Types Category. This restriction 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 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 might 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 can't be restored, and all associated child items, such as test results, are also removed. Additionally, bulk deletion of test artifacts isn't supported; attempting to bulk delete results 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.
Sign in to your organization (
https://dev.azure.com/{Your_Organization}).Select Boards > Work items
More actions > Move to team project.
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.
Use AI to find and update misclassified work items
If you have the Azure Boards MCP Server connected to your AI agent in agent mode, you can use natural language prompts to find work items that need to be moved or reclassified.
| Task | Example prompt |
|---|---|
| Find misassigned items | List all bugs in area path <Contoso>\\OldTeam that should be moved to the new team |
| Check items before moving | Show me all work items assigned to <Jamal> in the <Contoso> project with their work item types and states |
| Update fields after move | Update the area path of work items #101, #102, and #103 to <Contoso>\\NewTeam |
| Find items by wrong type | List all tasks in the backlog that have story points assigned, which might need to be user stories instead |
| Identify cross-team items | List work items in <Contoso> where the assigned team member's team doesn't match the work item's area path |
| Audit recent moves | Show work items in <Contoso> where the area path changed in the last 14 days |
| Find items needing reclassification | List bugs in <Contoso> that have child tasks, which might need to be user stories instead |
| Bulk reassign area path | Update all active work items in area path <Contoso>\\TeamAlpha> to area path <Contoso>\\TeamBeta> |
| Preview move impact | Show the count of work items by type and state in area path <Contoso>\\OldTeam> so I can plan the move |
| Find stranded items after reorg | List work items in <Contoso> with area paths that don't match any current team's area path configuration |
Note
Agent mode and the MCP Server use natural language, so you can adjust these prompts or ask follow-up questions to refine the results. The MCP Server can update fields like area path and iteration path but can't change work item types or move items between projects.