Moving a Jira issue to another project can look simple until the destination project uses different workflows, permissions, issue types, or required fields. One wrong setting can hide the move option or create a ticket that no longer behaves correctly.
That uncertainty becomes frustrating when you need to preserve comments, attachments, links, history, and ownership during a busy release. You may also worry about breaking reports or losing the issue’s original context.
But here's the truth: Jira can move an issue safely when you prepare the destination project first. This guide shows the exact process, explains common restrictions, and helps you verify everything afterward.
How to Move a Jira Issue to a Different Project
To move a Jira issue to another project, open the issue, select the Move action, choose the destination project and issue type, map any required fields, then confirm the change.
You need the right project permission before starting. In many Jira configurations, moving an issue requires the Move Issues permission in the current project and the Create Issues permission in the destination project.
-
Open the issue you want to move. Go to the issue’s full detail view rather than a compact board card. The full view usually exposes the available actions menu.
-
Open the action menu. Select the three-dot menu near the issue title. Look for Move, which may appear under additional actions.
-
Choose the destination project. Select the project that should own the issue after the move. Check the project name carefully if several projects have similar names.
-
Select the destination issue type. Jira may ask whether the issue should remain a Task, Bug, Story, Epic, or another available type. Choose a type supported by the destination project.
-
Review field mappings. Jira may show fields that exist in one project but not the other. Map values where possible, and enter anything the destination project requires.
-
Review the confirmation screen. Check the destination project, issue type, status, assignee, priority, and required fields before continuing.
-
Confirm the move. Select Move or the equivalent confirmation button. Jira then updates the issue key and places the issue under the new project.
-
Verify the result. Reopen the issue and check its key, project, workflow status, comments, attachments, links, watchers, and important custom fields.
The issue key usually changes because the project key is part of that identifier. For example, SHOP-142 might become WEB-318.
Jira commonly redirects the old address to the new issue location, but you should still update important references. This includes sprint notes, release pages, saved filters, automation rules, and team communications.
What Changes When You Move an Issue?
A project move changes more than the issue’s location. Jira may recalculate the issue key, workflow behavior, available fields, permissions, and board visibility.
The issue key usually changes
The issue key combines a project key with a sequential number. Moving an issue to another project often gives it a new key under the destination project.
For example, APP-77 could become OPS-214. The issue itself remains the same Jira item, but references that display the old key may need attention.
The workflow may change
Projects can use different workflows. A Bug in one project might have statuses such as Open, In Progress, and Resolved. The destination project might use To Do, Doing, and Done.
Jira may ask you to map the current status to a valid status in the destination workflow. If no direct match exists, choose the closest operational equivalent.
Fields can become unavailable
Project screens and field configurations determine what you can view or edit. A custom field used in the original project may not appear after the move.
Consider a “Customer Segment” field that exists only in a sales project. Moving the issue into an engineering project may remove that field from normal screens.
Boards and reports may change
Boards usually rely on filters, project keys, issue types, labels, or status conditions. A moved issue may disappear from its previous board if the filter excludes the destination project.
For example, a board filtered with project = APP will not show an issue after it moves to OPS. The issue is not lost; the board simply no longer matches it.
Prepare Before You Start the Move
A short preparation check prevents most surprises. Think of the move as changing the issue’s working environment, not merely changing its label.
Confirm permission access
Ask a Jira administrator or project administrator to confirm your access if the Move action is missing. Do not assume your ability to edit an issue includes permission to move it.
A person may edit every field in a project yet still lack permission to create issues in the destination project. That difference commonly blocks the process.
Compare the two projects
Review the current and destination projects side by side. Check their issue types, workflows, required fields, priorities, components, versions, and screens.
For example, the original project may require a component while the destination project requires an affected version. Prepare both values before opening the move dialog.
Record important references
Copy the current issue key into your notes before moving it. Also identify important dashboards, saved filters, automation rules, sprint views, and external references.
This simple step gives you a reliable way to find the issue if the key changes immediately after confirmation.
Check linked work
Review parent links, subtasks, related issues, dependencies, and external references. Jira normally preserves issue links, but their meaning may need a quick review after the move.
If a subtask belongs to the original project, Jira may apply additional rules. Check parent and child relationships rather than assuming every related item moved with the main issue.
Consider timing
Move issues away from active sprint planning, release coordination, or large bulk updates when possible. A quiet window makes verification easier.
For a single low-risk task, the delay may be minor. For a release-blocking Bug, coordinate with the team before changing ownership or board visibility.
Field Mapping and Workflow Decisions
The move dialog is where Jira translates one project’s setup into another. Slow down here, especially when the projects serve different teams.
Map issue types carefully
Issue types may have similar names but different purposes. A “Task” in an operations project may represent a request, while a “Task” in an engineering project may represent implementation work.
Choose the destination type that matches the team’s process. Changing a Bug into a Story only to bypass a restriction can create inaccurate reporting.
Handle required fields
Jira may require fields that were optional in the original project. Common examples include component, priority, fix version, environment, team, and acceptance criteria.
Use meaningful values rather than placeholders. If the destination project requires a component and the correct component does not exist, pause and ask an administrator for guidance.
Map statuses with care
Status mapping affects what the team sees next. A status such as Ready for Test should not automatically become Done simply because the destination workflow lacks an exact match.
Choose a status that preserves the issue’s real progress. If the move changes the workflow, add a comment explaining the transition and any follow-up action.
Review assignee and reporter values
The original assignee may not belong to the destination project or may not have access to its issues. Jira can require a different assignee during the move.
Check the reporter too. Maintaining the original reporter supports accountability, while changing it may be necessary when project permissions differ.
Verify the Issue After Moving It
Verification should take only a few minutes, but it protects against silent workflow and visibility problems.
| Area to check | What to verify |
|---|---|
| Project and key | Confirm the destination project and new issue key. |
| Issue type | Make sure the selected type matches the team’s process. |
| Status | Check that the status reflects the issue’s actual progress. |
| Assignee | Confirm the responsible person still has access and ownership. |
| Fields | Review priority, component, version, labels, and custom values. |
| History | Check the activity timeline for the move and related changes. |
| Links | Open parent, child, blocked-by, and related issue links. |
| Board visibility | Confirm the issue appears where the destination team expects it. |
Test search and board visibility
Search for the new issue key and use a project filter to confirm the issue appears in its new location. Then open the destination team’s board.
If the issue does not appear, inspect the board filter, status mapping, sprint assignment, and issue type conditions.
Review automation effects
Automation rules can trigger when a project changes, an issue type changes, or a field receives a new value. Check the issue history for unexpected transitions, comments, or notifications.
For example, a rule that assigns every new Bug to a quality team may run after the move. That behavior might be correct, or it might require an administrator’s adjustment.
Tell the people who depend on the issue
Send the new key to the assignee, reporter, project lead, and anyone tracking the work. Include the old and new keys so people can connect the change quickly.
A short message such as “APP-77 is now OPS-214 in the Operations project” prevents duplicate work and broken references.
Using ONES.com for Cross-Team Work Management
When project moves happen often, a broader work management platform can help teams organize work across departments. ONES.com provides capabilities for coordinating projects, requirements, tasks, defects, and delivery activity in one workspace.
This does not remove the need to understand Jira permissions or workflows. It can, however, give teams a consistent operating layer when several departments manage connected work.
Capabilities that support project coordination
- Project planning: Organize milestones, schedules, ownership, and delivery objectives across teams.
- Task management: Break larger initiatives into assignable work with due dates, priorities, and progress tracking.
- Requirement management: Connect business needs with implementation work and acceptance expectations.
- Defect tracking: Record defects, assign responsibility, and follow resolution progress through defined stages.
- Workflow configuration: Create process stages that reflect how each team evaluates and completes work.
- Cross-team visibility: Give stakeholders a shared view of progress, blockers, dependencies, and ownership.
- Permission controls: Limit access according to teams, roles, projects, or business responsibilities.
- Reports and dashboards: Monitor delivery trends, workload, status distribution, and overdue activity.
For example, a product team could manage a customer requirement, its engineering tasks, quality checks, and release milestone in one connected workspace.
The practical benefit is fewer handoffs between disconnected tracking areas. Before adopting any platform, compare its workflow depth, migration support, permissions, integrations, and reporting needs with your team’s process.
Common Challenges
The Move option is missing
Problem: You open the action menu, but Jira does not show a Move option.
Solution: Ask an administrator to check your Move Issues permission in the current project and your ability to create issues in the destination project. Also confirm that your Jira edition and project type support the action.
Jira rejects a required field
Problem: The move stops because a field has no value or the current value is invalid.
Solution: Read the validation message carefully, then enter a value accepted by the destination project. If no suitable value exists, ask the destination project owner to add an option or adjust the field requirement.
The issue disappears from a board
Problem: The move succeeds, but the issue no longer appears on the previous board.
Solution: Check the board filter first. A filter restricted to the old project key will exclude the issue after its project changes. Search for the new key to confirm the issue still exists.
The workflow status does not match
Problem: The destination project uses different statuses, so the issue appears earlier or later than expected.
Solution: Review the status mapping during the move. Select the closest valid status, then add a clear comment explaining the issue’s progress and next action.
People keep using the old key
Problem: Team members continue referencing the original issue key in messages, filters, or planning notes.
Solution: Share the new key immediately and update important saved searches, reports, dashboards, and written references. Keep both keys in the announcement for clarity.
FAQs
Can I move an issue between Jira projects?
Yes, provided your Jira permissions and project configuration allow it. Open the issue, choose the action menu, select Move, then choose the destination project and issue type. Jira may require field mapping before confirmation. If the option is unavailable, an administrator should check your project permissions and the destination project’s settings.
Will moving an issue change its key?
Usually, yes. Jira issue keys include the project key, so moving an issue commonly creates a new key under the destination project. For example, CORE-45 may become SUP-208. Record the old key before moving, then share the new key with anyone who tracks the work.
Are comments and attachments preserved after a move?
Jira generally keeps the issue’s comments, attachments, activity history, and links when you move it. Still, verify these areas afterward. Permission changes, field configuration, and project-specific behavior can affect what you can see or edit in the destination project.
Can I move an issue into a different issue type?
Often, yes. Jira may let you select another issue type during the move, provided that type exists in the destination project. Choose carefully because issue types can control screens, workflows, required fields, reports, and automation. Do not change the type merely to bypass a validation message.
Why can’t I move a Jira issue?
The most common reasons include missing permissions, an unsupported destination project, incompatible issue types, required fields, workflow restrictions, or an invalid field value. Review the message Jira displays. If it remains unclear, ask a Jira administrator to compare the current and destination project configurations.
Conclusion
Moving a Jira issue to another project is safe when you prepare the destination, map fields carefully, and verify the result afterward.
The main risks are missing permissions, incompatible workflows, required fields, changed issue keys, and lost board visibility. A quick pre-move review prevents most of them.
But here's the truth: the move itself is only one step. The reliable process includes preparation, field mapping, confirmation, verification, and clear communication.
When you follow that sequence, you can relocate work without losing context or confusing the people responsible for completing it.
Top comments (0)