JIRA - Move an Issue

Jira - Move an Issue

Jira provides a powerful feature to move an issue from one project to another, or to change its issue type within the same project. This is useful for correcting mistakes, reorganizing work, or adapting to evolving project structures.

Steps to Move an Issue

The process of moving an issue involves a wizard that guides you through the necessary changes. Here’s a general outline:

Step 1: Initiate the Move

• Navigate to the issue you want to move. Open the issue view page.
• Look for the ‘Actions’ menu (often represented by ’…’ or a similar icon) or a ‘More’ dropdown menu on the issue view page.
• Select the ‘Move’ option from this menu.

This action will launch the ‘Move Issue’ wizard.

Step 2: Select Target Project and Issue Type

• New Project: Choose the destination project to which you want to move the issue. If you are only changing the issue type within the same project, select the current project.
• New Issue Type: Select the desired issue type in the target project. Even if moving within the same project, you might want to change an issue from a ‘Task’ to a ‘Bug’, for example.

After making your selections, click ‘Next’. This step is crucial as it defines the fundamental change in the issue’s context.

Step 3: Update Status (If Applicable)

• If the workflow of the target issue type (in the target project) is different from the source, Jira will prompt you to select a new status for the issue.
• Choose an appropriate status from the available options in the target workflow that corresponds to the issue’s current state.

This step ensures the issue fits correctly into the workflow of its new context. Click ‘Next’ to proceed.

Step 4: Update Fields

• This is a critical step. The target project or issue type may have different field configurations (e.g., different custom fields, required fields, or field options).
• Jira will automatically map fields where possible (e.g., Summary, Description).
• For fields that don’t map directly or are required in the new context but not the old, you’ll need to provide values.
• For example, if the target project has a required custom field ‘Department’ that the original issue didn’t have, you’ll need to select a value for ‘Department’.
• Pay attention to fields like ‘Affects Versions’, ‘Fix Versions’, and ‘Components’, as these are project-specific. You’ll need to select appropriate values from the target project.

Review each field carefully and update as necessary. Click ‘Next’.

Step 5: Confirmation

• Jira will display a summary of all the changes that will be made to the issue (new project, new issue type, status changes, field value updates).
• Carefully review these changes to ensure they are correct.
• If you need to make any adjustments, you can click on the relevant step in the navigation panel on the left side of the wizard to go back and modify your selections.

Once you are satisfied with all the changes, click the ‘Move’ button to finalize the operation.

Step 6: Issue Moved

• The issue will be moved to the target project and/or updated to the new issue type.
• The issue key might change if it’s moved to a different project (e.g., from OLDPROJ-123 to NEWPROJ-45). Jira usually creates a link from the old issue key to the new one for traceability.
• The issue will now adhere to the workflow, field configurations, and permissions of its new project and issue type.

The moved issue will be displayed, reflecting its new context. You can further edit it if needed.

Important Considerations When Moving Issues

• Permissions: You need ‘Move Issues’ permission in the source project and ‘Create Issues’ permission in the target project.
• Workflows: Status mapping is crucial if workflows differ significantly. An issue’s history will be retained, but it will transition to a new status within the target workflow.
• Field Data Loss: If the source issue has data in fields that do not exist in the target project/issue type, that data might be lost unless explicitly mapped or handled.
• Links and Sub-tasks: Issue links and sub-tasks are generally preserved, but always verify this after the move. Sprint information might be affected if sprints are not shared across projects.
• Issue Key Change: Moving to a different project will result in a new issue key. While Jira often links the old key, update any external references if necessary.

Practical Application Scenarios

• Incorrect Project: An issue was accidentally created in the wrong project.
• Reorganization: A feature initially tracked in one project becomes part of a larger initiative in another project.
• Issue Type Change: A ‘Task’ is later identified as a ‘Bug’, or a ‘Story’ needs to be broken down and its original ticket reclassified as an ‘Epic’.
• Archiving: Moving issues from an active project to an archive project (though Jira has dedicated archiving features for this now in some versions).