REST API to move issue from one project to another

[Sarangadhar.Sahani]

I need a reference to the REST API that I can use to move an issue from one project to another. Kindly help.

[Nic Brough -Adaptavist-]

There is no REST API for moving issues yet.

It's not something you should be automating or scripting for really, it's not something you should do regularly.  If you are regularly moving issues between projects, you've probably got a broken process.

[Sarangadhar.Sahani]

Ok thanks for confirming. Then what is the process o bulk move and how to I get the old and corresponding new keys after bulk moving.

[Kevin Phillips]

NOTE: bulk-move of issues may be something that is not done frequently, but if you need to do complex moves of many issues it can prove problematic to do so using the web UI even if it only happens occasionally. Take for example this use case: you import thousands of issues from another issue tracking tool into Jira and, for simplicity, you dump all the new issues into a single project. However, afterwards suppose you want to split up that data between dozens of new projects in Jira. Trying to create JQL queries for each one of the secondary projects, and manually migrating the issues one project at a time, would be very time consuming and error prone. It would be very handy to have support for this added to the REST API.

[John Price]

This is an old question but I have this problem and it's to Move issues from one issue type to another within a project as part of cleaning up issue types.  For example someone created "Sub Task - QA" in the past but we want everyone to just use "Sub-Task".  In the UI, changing issue type within a project is a Move and has the same problems.  The other way is to update the issue type scheme - removing the old type - which forces a bulk Move, but that has scalability issues and does not work for more than 1000 issues.  

[Nic Brough -Adaptavist-]

Bulk-edit is still the fastest way to do this (as it goes through all the checks that need to be made and asks you about the minimum changes needed)

[Matthieu Paret]

We cannot move issue between team managed project without copying manually the fields so yes JIRA is really broken :/ 

[Nic Brough -Adaptavist-]

That's another step, yes, because team-managed and company-managed projects are a totally different shape.  To abuse an analogy one of my colleauges uses - when you're trying to attach a couple of bits of wood together, Jira Server uses screws and Jira Cloud (company managed projects) uses nails.  To add to it, Team-managed projects use nuts and bolts.

It's not "broken" though, just very hard to convert between three different ways of doing things.  And thats' why there's no REST API for it - it needs so much conversion...

[Mike Hayes]

Despite the complexity, there are many, many, valid reasons for adding Move to the API that don't necessarily mean there's a "broken process."

"Move" also includes converting issue types. With the improvements in Advanced Roadmaps + Hierarchy, there are many use cases where an issue type might be "moved" to a different type, e.g., convert a standard issue type to a subtask type of another issue, or covert and Initiative to an Epic, etc.

At scale, moving issues between projects is also a valid use case. E.g., issues identified in the field, on the line, during a test; they can be collected in one project, triaged, and then moved to the appropriate project (unless we train 10K+ users which of the hundreds Jira projects is the correct one to log a specific issue).

A workaround is to clone the issue and delete the original, but there are downsides, like losing the original URL. 

Lack of a Move API (in Cloud) can severely limit an organization's abilities, especially at scale.

[Nic Brough -Adaptavist-]

Mmm, I still don't have any example of a good process that would include "move to another project" as standard.

The only process you have mentioned here is "triage".  But that immediately begs the question of "why are your issues not being put in the right place to begin with?".  It suggests that the "create issue/request" process is not gathering enough information, is poorly designed (in terms of what the person raising them sees, not the actual data - a poor "customer journey"), or that your projects are not set up along the lines along which you actually work in real life.

You also say "unless we train 10K+ users which of the hundreds Jira projects is the correct one".  Yep, I see that.  But how about setting it up so that they mostly don't need that training?  

There is nothing wrong with moving issues between projects (or even types), but the only good reasons I've seen for doing it are housekeeping, exceptional error, or, on a very exceptional basis, "we've done enough work on this to establish it is in the wrong place".

[Inna S]

Another use case of triage is here.

Say, we have two components that make up a product: one is 'core', the other one is 'reports'. Each is developed by its own dedicated team, on dedicated Jira Project. The customer sees the problem with the product, the support team verifies it is in the 'report ' section and adjusts the component name to 'reports'. 

All the support items are in the same dedicated 'Support' project for many more products.

So support now requests the Dev help. They create an issue for this by transitioning the support issue to the 'pending dev' status. No manual copying of all the fields, right?

One would expect the issue created in the group's project.

But not in Jira: because 'create issue' automation can only have the target project preset in the rule.

Target project for issue creation in Jira automation can not accept a variable.

If you have 10 products with 10 possible target projects - good luck. Enjoy the endless if-else. Till you hit the limit of the number of steps in your rule, that is not that high anyway (60 as of the time of writing).

Let's say we go along and create all field issues for Dev in one 'central' project. And adjust the dev project boards to include the relevant issues from the 'central' dev project. It even works for dev project sprints. All good.

Till we get to Releases. Because Releases are linked to projects, in addition to boards.

And one can't include issues from 2 projects in a single release. You get to create a copy of the release in that other project. Otherwise Jira Roadmap will not work at all - because your board filter now includes the issues from the foreign project.

Of course, the automatic Release copying only copies the Release end date, but this is really minor inconvenience now. Because you have a joy of syncing releases and adjusting your filters and OOB Release report does not make any sense now.

How convenient. 

One would wonder if we could create the dev work item in the 'central' project and then move it to the proper destination project. Nope, no API for this.

Moving issues comes with its own fun, because Jira changes the issue key, but we kind of designed the process to overcome this.

But of course, Jira is not broken but the real world businesses are. Sure.

[GeoffL]

Mmm, I still don't have any example of a good process that would include "move to another project" as standard.

...

There is nothing wrong with moving issues between projects (or even types), but the only good reasons I've seen for doing it are housekeeping, exceptional error, or, on a very exceptional basis, "we've done enough work on this to establish it is in the wrong place".

So there are three good reasons.  Add 'legacy migrations' as a fourth.  

[Mike Hayes]

@Nic Brough I almost always agree with you, especially with the “fix the process” argument, but that is usually  true for strict processes like software development. As Atlassian moves into more business-oriented use cases that utilize Jira Work Management, the processes are more varied. 

No matter how much training a team does, it’s confusing and frustrating for them when they say, “Actually, I thought this was a standard issue type (Level 2 in the hierarchy e.g, Task), but it makes more sense to move it “up” one level to a Project (Level 3) and then put that Project under this other Initiative (Level 4). (I’m purposely not using the word “Epic” (Level 3) here to keep things simple). 

Organizing and re-organizing items within a hierarchy, which requires Move, is far too cumbersome in the JSM/JWM/JSW framework; especially when it’s “super easy to do that” in competitive products like Airtable, Smartsheet, Asana, Monday, etc.

When users learn everything they need to do to organize their issues, it becomes a non-starter. So those teams start to use those other products.

Then, when it’s budget season, companies start to say, “Why are we paying for multiple products that do the same thing?” and “Jira’s just for software developers, so let’s cut back on our licenses and let the ‘business teams’ use Asana.”

Atlassian wants to do more than meet the needs of agile software teams, they want to win over those business teams, like marketing, and finance, and sales; and that requires more flexibility for less hardcore users (and team-managed projects isn’t the answer in many situation).

Like I said, I’ve read perhaps 2,000 of your replies over many, many years, and I’ve leaned a lot, and generally agree with you (even though you can be stubborn, and a little righteous), but I think you’re wrong on this one: an easy way to to move (organize) items is a foundational requirement if Atlassian wants to expand their footprint. 

[Nic Brough -Adaptavist-]

I see all of that and broadly agree, of course, but one thing sticks out to me.  Not because it's wrong, but because I've had to suffer it for decades (not just the two Jira has been here for) and it just feels broken.

>Organizing and re-organizing items within a hierarchy, which requires Move

Why are people needing "move" to re-organise their hierarchy?  Does that not mean that they don't understand what level things they are raising are at?

[GeoffL]

On the contrary, it means that they didn't understand the level to raise things, but now they do.  So they need to move things from the old level to new level

Or it means that they used to understand the right level, but then Atlassian made lots of changes over the years, and now the right level has changed.  

In my case, Atlassian has made lots of changes to Business Projects and Software Projects so the functionality each offers is now significantly different.  What worked just fine as a Business project 5 years ago now needs to be a Software project.  I need to migrate the thousands of legacy issues, with data that we are contractually required to keep, over to a new project. 

Doing that manually on a complex project sounds like a recipe for disaster.  

[Nickson HS Hsu _許弘昇_]

I have a question.
If I want to backup specific project issue. but the issue type is not Jira raw issuetype , the issue it xray issuetype.
But Jira Automation rule doesn't have move issue and JIRA API alson doesn't have move issue.
So if you want to backup the issue of xray, is there any other way?

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Please see the previous answers.

Why are you trying to do this?  Do you have a broken process?

[Nickson HS Hsu _許弘昇_]

because some team members want to backup the project issues to prevent issues lost

[Nic Brough -Adaptavist-]

Moving issues is not a backup.

If you need to prevent issue loss, remove the permission to delete issues from all the users.