Move It for Jira Admins

Move issues between Jira projects automatically - by rule, by JQL, or on workflow transition - with field mapping that doesn't break the destination.

Product: Move It Audience: Jira Admins
Get Move It on the Marketplace ↗

Why this matters for Jira admins

Moving issues between projects is one of those tasks that’s trivial in concept and miserable in execution. Jira’s native UI handles single-issue moves but doesn’t preserve sub-task hierarchy well and doesn’t handle field-option mismatches. Bulk Edit’s Move Issues works but loses context. And both require an admin to sit through the operation, which doesn’t scale to the volumes most large Jira instances actually need.

Most admins end up with a backlog of “please move these tickets” requests that they batch up and do during maintenance windows. Move It eliminates the batching by making the moves either fully automatic (rules and transitions) or fully bulk-operable (by JQL). The admin’s job changes from “do the moves” to “define the rules that do the moves.”

The automation-rule alternative

Jira’s native Automation engine can move issues via the Move action - it works for simple cases. Where it falls down:

  • Field mapping across mismatched option lists is brittle.
  • Sub-task and link handling has known edge cases that break in production.
  • Debugging is hard because the rule runs in the Automation log, not as a discrete operation.

Move It treats moves as a first-class operation with its own UI, logs, and dry-run mode. For complex moves

  • the field mapping non-trivial, the volume high, the destination project requiring custom logic - Move It is the more reliable path.

Where to start

Most admins adopt Move It in two phases:

  1. Phase one: replace the manual queue. Pick the two or three move workflows that consume the most admin time (intake-to-product, support-to-engineering). Convert those to Move It rules. Free up the hours.
  2. Phase two: automate the boundary cases. Reorganisations, team splits, and project consolidations become “define the JQL and the mapping, run the rule, audit the results” instead of multi-day projects.

What jira admins are dealing with today

  • Native Jira move-issue UI handles one issue at a time and breaks fields whose options differ between source and destination.
  • Bulk Edit's 'Move Issues' option works but loses sub-tasks, breaks linked issues, and the field-mapping UI is awkward.
  • Triage workflows that need to move issues automatically (intake project -> the right product project) end up as fragile Automation rules.
  • Admins spend hours per quarter on 'please move these 47 tickets to the new project' requests.
  • Reorganisations and team splits require moving thousands of issues with consistent field mapping; nobody wants to do it by hand.

How Move It helps jira admins

Automated moves on rule

Define a move rule once - source project + JQL + destination project + field mapping - and Move It executes it on schedule or on demand. The fragile per-ticket clicking goes away.

Move on workflow transition

Wire a move to a workflow transition so an issue automatically moves when its status changes (e.g., 'Approved -> ' moves it from the intake project to the destination project).

Bulk moves by JQL

Move all issues matching a JQL filter in a single operation. Useful for reorganisations, team splits, and consolidations.

Field mapping that survives

Map source fields to destination fields explicitly, including custom-field option translation, default values for missing fields, and skip-rules for fields that don't apply. The destination project ends up consistent.

Sub-task and link preservation

Sub-tasks move with their parent; issue links rewrite to the new keys; attachments and comment history transfer cleanly. The destination ticket is functionally identical to the source minus the project key.

Use cases

  1. Intake-to-product routing. A central intake project receives requests from multiple sources. Triage assigns a 'Destination Project' field; Move It moves the issue to the assigned project on workflow transition. The intake admin never moves tickets manually.
  2. Team reorganisation. When teams split or merge, thousands of issues need to migrate to new projects. Move It handles the move-by-JQL operation with field mapping for the new project's required fields.
  3. Customer escalation routing. JSM support project escalates to engineering projects. Move It moves the issue (or clones it) when the escalation transition fires, with the customer fields mapped to engineering-meaningful fields.
  4. Cleanup of legacy projects. Old project being archived; remaining open issues need to move to active projects. Move It handles the bulk operation with per-issue destination via a custom field.

Common questions from jira admins

Does Move It preserve sub-tasks during a move?

Yes. Sub-tasks move along with their parent issue. The sub-task hierarchy is preserved in the destination project. If the destination project doesn't have the original sub-task issue type, Move It maps to the closest available type or to a default that you configure.

What happens to issue links pointing at moved issues?

Issue links rewrite automatically. A 'blocks' link from PROJ-X to OLDPROJ-100 becomes a 'blocks' link from PROJ-X to NEWPROJ-100 after the move. The link types are preserved as long as both projects have them defined.

Can Move It move issues across Jira instances?

Within a single Jira instance, yes. Cross-instance moves (one Cloud site to another, Data Center to Cloud) require migration tooling beyond Move It's scope - Atlassian's official migration tools handle those. Move It is for moves within an instance.

What about the issue key - does it change?

Yes, the issue key changes to match the destination project's prefix. Move It records the old key as a custom field so historical references and external URLs can still find the issue. Jira's native redirect for the old key continues to work.

Can moves be reversed?

Each move can be undone by running the inverse rule - move it back to the original project. The move event is logged so you can identify what to reverse. Most admins build the reverse rule once for safety and keep it disabled until needed.

Try Move It for your team

Move It works for jira admins on Jira Cloud and Data Center. Install from the Atlassian Marketplace, or read the main Move It page for the full feature list.

Try Move It on the Atlassian Marketplace ↗   See the full Move It overview →

Also built for

Move It solves a different problem for each team: