Moving tickets from one project to another without losing it in the original project

[Madhu_Rathnasekar]

Hi,

We're setting up different projects for each team. Every ticket created will move through a workflow within its project being handed off to the next team, who will create a new ticket in their project and work on it. I wanted to know if there is a way to move tickets from one company-managed Jira project to another, without losing that ticket in the original project? In essence, a copy of the original ticket must be moved to the new project and it must adopt the new project's tag. 

Thanks in advance for any help!

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

An issue can only be in one project at a time.  If you move an issue to another project, it can't be in both projects at the same time.

You can clone an issue though, then move the new version to the other project.  The clone process links the two issues together as well, so you can see where the new one came from.

Bear in mind that if the two projects are configured differently, you may lose data on the issue you move.

[Garret Duffy]

@Nic Brough I am interested to move a ticket to another project as part of an Automation.  However, I note that "moving" an issue technically can't be done in an Automation. 

Instead, the original ticket is cloned directly to the project and the original ticket is deleted.

I was wondering if you had any advice regarding any unforeseen consequences to moving an issue using this workaround?

Thanks

[Nic Brough -Adaptavist-]

Moving issues between projects is not something you should automate or have as a part of a regular process.

The short version of my opinion here is "stop".  Your process may well be fine, but you have not set up Jira to match it.  Clone, move and delete are all things you should be running away from.  If you're using them, you probably have a problem with your process as it is mapped on to Jira.

I would want to take another look at your processes and then talk to your Jira admin about how best to support them!

[Garret Duffy]

We have multiple Product and multiple Development teams.  Each team has their own JIRA project but Product teams share the same workflow status definition and Development teams have their own workflow status definition. 

Issues are advanced along a Product team's workflow until the final workflow stage.  Development team then reviews those "final stage" issues, toggles a custom field to "Ready" and then someone manually moves those toggled issues, to one of the Development teams' projects (destination project).  In the destination development project, one or more tasks are generated for the moved issues and those tasks are then advanced along the Development team's workflow.

I am enquiring about the underlined text above and how to make more efficient.

[Nic Brough -Adaptavist-]

It's the same answer, stop moving issues between projects, it's not the way to work in Jira.

You need to do one of:

• Change your processes such that people create issues in the right project to begin with
• Merge the projects so that people don't need to have to work out which project is right
  • (Both of the above would mean merging your workflows - the product team would own the first few status, the development the later ones)
• Automate the product team's workflow so that when they move an issue to ready (I'd strongly recommend doing this with status rather than with a custom field), it creates a linked copy in the relevant development project.  Then automate the development project so that when a linked issue from product is moved to "done" by the developers, have it move the product issue to "development done"

[Garret Duffy]

The third option looks good for us and is close to what we're doing already.  The final automation step you describe looks very useful and I will try to make that happen.  

Thanks so much.

[AJ McBride]

@nic I'm curious what your solution would be with this scenario;

We have a service manager project, where our Customer Success Operations team intake requests from CS employees; sometimes though requests are large and are moved to another project to be fit into a sprint

Currently we move the tickets from the service manager project to the sprint project; work off the ticket and complete the ticket

Based on the conversation here; it sounds like we should be cloning the ticket with a status like you mentioned; and complete one with the other through automation.

Thoughts?

[Nic Brough -Adaptavist-]

Not quite.  I would not clone-and-move.  (I would certainly never move the issue out of the service project - that destroys the data representing your link and conversation with the customer/requestor)

If it is a proper JSM project, with requests for the customers, and issues for the agents (they have a 1:1 relationship), then there is a function on the issue the agents have for "create linked issue". 

This lets them go straight into a "create issue" process which 

• Lets them choose a target project (your sprint project)
• Defaults some of the fields based on the request and issue data in the service project
• Links the two issues, so that you can easily set up automations like "tell agent the developers have marked the linked issue as done" or "copy developer comment to Agent's issue"

It's a convenient shortcut, and it's not quite "clone", but I prefer it to clone because it gives the Agent the opportunity to add more, and you don't have to mess around with the horrors of moving anything.

[AJ McBride]

@Nic Brough thank you for this, i will test and review with my team!

[Marlene Kegel - codefortynine]

Welcome to the community, @Madhu_Rathnasekar.

I am Marlene from codefortynine.

With our Jira cloud app Deep Clone for Jira, you can clone and move tickets between all project types.

• Simply select the issue you want to clone
• Define the target project and issue type
• Configure which fields you want to clone

If you clone on a regular basis, you can create presets for recurring cloning actions.

If you want to clone several issues at once, you can use the Bulk Clone feature.