Browse guides

Move a work item to another space in Jira

Moving a Jira work item changes its space key, but it does not guarantee that every field or workflow value has an equivalent in the destination. Treat the Move screen as a migration checklist, not a quick housekeeping action.

Company and team-managed spaces

The Move wizard is the same in both space types. You need permission to move the source work item and to create the chosen work type in the destination; team-managed spaces label the source permission Move any work item.

  1. Check the destination before moving

    Confirm the destination has an equivalent work type, workflow status, and required fields. Ask its admin about components, versions, and custom fields that do not exist there.
  2. Open More actions → Move

    Open the work item, select More actions (•••), then choose Move.
  3. Choose the destination space and type

    Select the destination space and its target work type. The type may need to change when the destination does not offer the source type.
  4. Map status and complete fields

    Pick the appropriate destination status, then fill every required field. Jira cannot carry a value into a field that is unavailable in the target configuration.
  5. Review and confirm

    Confirm the summary of changes, then inspect the moved item. Its key updates to the destination space key; Jira redirects links to the old key automatically.

Good to know

The work item moves; every space-level configuration does not:

  • Keys change and old links redirect. Jira assigns the destination space key and redirects its old URL and links, but it does not rewrite plain-text references to the former key in comments or descriptions.
  • Check the Sprint field after a move. Sprint associations often do not survive a move, especially from a company-managed to a team-managed space, where work moves to the destination backlog. They can be retained when the source and destination share sprint infrastructure.
  • Status can be remapped. When the destination workflow does not offer the source status, Jira asks you to choose an equivalent. Check that choice before confirming.
  • Components and versions are space-specific. A move from a company-managed to a team-managed space permanently removes those values. Other destinations may also lack compatible configuration.
  • Custom fields can look blank after a cross-type move. Team-managed fields are independent of global company-managed fields, even where similar values remain stored on the work item.
  • Move one representative work item first. For a large migration, test the mapping before bulk-moving the rest.

Keep cross-space work visible

A single clear board view makes it easier to see what moved, what is blocked, and what needs attention next.

Try BetterBoard free

FAQ

Will I lose data when moving a Jira work item to another space?
Jira maps compatible data, but space-specific fields, workflow statuses, sprint associations, components, versions, and custom fields may not have equivalents. Check the confirmation screens and inspect the result.
Why can't I move a Jira work item?
You need permission to move the source item and to create the target work type in the destination. The destination may also not offer a compatible work type.
Does moving a work item change its Jira key?
Yes. Jira gives it the destination space's key and redirects existing links that use the old key.