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.  

[Tony Mottes]

@Nic Brough -Adaptavist- A bit late to the game, but coming from the service management world, it is not uncommon for customers to create their service requests (not incidents-which are far less complex) in the wrong place, resulting in an improper request type.  We do everything we can to prevent this, as it causes delays in fulfillment and a potential SLA breach, but it happens to the most well structured of ITSM organizations-and those are few and far between.  Unless your help desk is small and only uses one project and one issue type, this situation requires a reclassify solution.  

Delete and recreate is an option, although not a great one from a tech, customer, nor automation perspective.   Currently we do have an automation rule that allows for request type modification, but only within the owning project.  More often than not, the ability to reclassify does require a change in request type, issue type and/or project. 

To compound the problem, all members of the teams who receive automatically routed requests should have the ability to reclassify.  The move functionality is clunky for this process and doesn't account for request type.  

We should be able to POST to an API method a JSON containing all the parameters needed to perform the move action, then we can continue an automation rule that finishes up the process and notifies the new team. 

[Nic Brough -Adaptavist-]

No, that's valid, but it proves the point - move is not something that should be routinely done, you need to think about it.

[Melih Kocaadam]

Hi @Nic Brough -Adaptavist- 

I don't understand why so many people have to convince you. There are dozens of different reasons for customers to need a transport method on the API. Why are you ignoring this?

- Could your processes be faulty?
* Yes it's faulty, I'm overhauling issue types to fix process errors. (I'll probably do it in the future too)
What are we discussing, our needs?

[Nic Brough -Adaptavist-]

Yes, there are dozens of reasons people might think they want to move issues, but you need to be looking at why you want to move issues. 

If you find that you think you need to do it as part of a process flow, then you need to take a step back, and re-assess your process, because it's inefficient, confusing, and probably broken.

Your need here is to fix your process and information collection, not automate the moving of issues because people are doing the wrong thing.

If you're overhauling your issue types to fix your process problems, great, and yes, moving issues to different types is a perfectly valid thing to do to correct the data.  But there's no need to code for it, internally or remotely - do it manually, because you're only going to do it once, it's not worth the effort to automate or code it if you're not going to do it again after you've fixed your processes.

[David Pezet]

@Nic Brough -Adaptavist- First, big thanks for all the help over the years. Your posts are priceless.

Similar to some of the use cases mentioned above, we have a department that has several projects. Because users don't necessarily understand what project their request is associated with, to save them the trouble of figuring this out (so they can quickly return to their fast pace work), we have a central project for the user to create issues, and then the department triages these requests accordingly. This is a case of many users vs the few of a department, and constantly educating the many is way more costly than letting them say "This is a X department issue, they can run with it from there".  

Currently, we clone and link the issues, but this gets messy because then we also have to clone comments/attachments, sync fields etc between the two, because users get confused at which they are looking at. (Because some will comment on one issue without tagging people who might not be watchers on the other, and check the original and don't pay attention to the linked issues etc. etc.)

While standardizing project configuration helps with manually clicking through the move process, this is still clunky to go through on a regular basis. What is the recommend process fix that gets to a place where the end user doesn't have to determine which of a departments' project is correct? 

Ideally we would like to leverage the drag and drop functionality of the boards to use transitions to move the issue to the corresponding project. Or even treat the Project breadcrumb like the issue types in the new view. If Project is on the edit screen, let them change it, even if it only works when the projects are using all the same necessary configuration schemes. That way when there are several Company Managed projects all using the same configurations, issues could move freely between them. If it can't exist as-is in the new project, then return an error, or maybe then open up the Move wizard, but I think just moving 1:1 would be incredibly nice.

[René Keller]

hey there,

Just adding myself to the large list of people who suffer from the lack of "move" support on the REST API.

For clarification upfront: I agree, this is nothing i'd like to do regularly.

However, there is this one occasion, where I'm facing the need to re-arrange a project structure with a homebrew DIY Epic Link type of thing - using a self defined custom field to reference the Epic-like issue - on our self hosted Jira Server instance. I'm currently preparing for migrating to cloud hosting and need to do all the cleanups. Therefore I'd need to move all the Epic-like issues to the new project where they shall be of type Epic. I'll need an Epic Name for them while moving, and I currently don't see any practical way of doing that without having to specify it for each and every one of them manually while moving them via batch processing. With more than 10,000 issues I'm looking for a way to automatically set the Epic Name (e.g. to the current issue key for the sake of simplicity) while moving. I cannot set it upfront, since the issues are not of type Epic, and thus the parameter is not available.

Any advice or alternative solutions would be very much appreciated.

Cheers
René

[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.