Copying or cloning an Epic to another JIRA Project

[Jose M Gonzalez]

I have a JIRA project which contains several Epics with User Stories. There is one Epic which is identical from one JIRA Project to another (GxP User Stories) which I will like to have in both projects. Can I copy (clone) the Epic from one project to the other so I can have the contents of that Epic in separate projects?

What happens if I clone an Epic with User Stories in it? Is a new Epic number assigned to the cloned Epic? How about the User Stories within the cloned Epic - do they get new numbers or do they keep the same User Story numbers?

Thanks in advance.

[Mark Segall · Accepted solution]

Hi @Jose M Gonzalez and welcome to the community!

Can I copy (clone) the Epic from one project to the other so I can have the contents of that Epic in separate projects?

Yes - This is possible with automation.  Assuming you're on Jira cloud.  Here's an example... On this rule, the user opens the epic, clicks Jira Automation, and executes this rule.  The rule then clones the epic to Project B and then iterates through all of the children issues and clones them as well (setting them to the new epic)

What happens if I clone an Epic with User Stories in it?

As you see in my example above, it's up to you.  My example rule will clone any related stories.  You could choose to ignore them, only clone based upon business logic, etc.

Is a new Epic number assigned to the cloned Epic? How about the User Stories within the cloned Epic - do they get new numbers or do they keep the same User Story numbers?

The source issues will retain their key.  Cloned issues will get a dedicated new key tied to their destination project (e.g. PROJECTB-123). 

[Mark Williams]

Mark,

Is there a way to provide the user a list of projects and for them to select multiple projects to clone the issues to? I have a user that would like to clone the Epic and its stories to multiple projects and the list will change each time he/she runs the clone

Mark

[Mark Segall]

Hi @Mark Williams - Yes, but I've found this easiest to manage through Insight:

1. Create an object type for Projects with a minimum of the following attributes:
   • Project Name
   • Project ID
   • Issue Type ID (reference to Issue Types object)
2. Create an object type for Issue Types with the following attributes
   • Issue Type Name (e.g. Task)
   • Issue Type ID
3. Populate your object types accordingly
4. Create a custom Insight field to serve as a "Project Picker"

AUTOMATION

For the automation trigger you can go one of two ways:

1. Project Picker is updated - This is quick and easy because you just need to make sure the project picker field is available on the screen
2. Issue Transitioned - I've created a new status like "Clone Request" with a transition screen that has the project picker on it

The biggest thing about this approach is that you need to feed the clone project and issue type with a smart value based upon what was selected in your project picker.  For example...

Project

{{triggerissue.customfield_xxxxx.projectID}}

Issue Type

{{triggerissue.customfield_xxxxx.issueType.issueTypeID}}

[Arnd Layer]

@Mark Segallhave you considered also copying sub-tasks?

AFAIK, you can't nest branches in automation rules. So you would have to create a 2nd rule that is triggered by the 1st one and clones sub-tasks for each cloned task.

One could use a hidden filed as trigger. I've created a custom field "admin-label" (type: labels) that does not appear in any view for this use case.

The problem is that I also need to know the task-level issue that has been cloned. So I would have to branch out using the linked issues branch, which the again would require nested branching to iterate over the subtasks. So this looks like a dead end as well.

Any ideas?

[Mark Segall]

Yes - Creating sub-tasks is a little more tricky, but possible. I provided an answer on that previously.  It's a long thread, but this link should take you to the relevant comment:

https://community.atlassian.com/t5/Jira-Software-questions/Re-Re-clone-an-epic-including-its-child-issues/qaq-p/2118393/comment-id/214327#M214327

[Tim Schmit]

@Mark Segall Perhaps a very stupid question, but I tried the above and the result is that the Epic is copied successfully. However, the issues (stories) in the source Epic have been cloned into the source Epic rather than the new Epic...

I also tried the automation rule that is now also in the public library and it has the same problem.

This is the error that is shown in the log (I log the previously saved variable, in this example PBE-479, so the variable value itself seems ok):

[Mark Segall]

Based upon the error you're receiving, it appears that your project is Team Managed.  These projects do not use Epic Link and thus would result in an error.  In that case, you would want to replace any instance of Epic Link with Parent

[Sherine Ashraf Safwat]

Hello Mark,

Could you please advise me what will be the smart value used when adding the epickey variable. I have a problem that the cloned issues are not linked to the new cloned epic (they have no epic link)

@Mark Segall 

Thank you

[Mark Segall]

Please see my comment above.  The variable is going to depend upon your project type (company vs team managed).

[Sherine Ashraf Safwat]

@Mark Segall My project type is company managed project, we use epic link normally. I think my problem is in smart value used. I tried issue.key and epic.labels

Thank you

[Mark Segall]

You Smart Value on the Create Variable should be

{{createdIssue}}

[Sherine Ashraf Safwat]

@Mark Segall It worked, thank you so much

[Mathieu Lepoutre _Exalate_]

Hi @Jose M Gonzalez 

I'm working as a pre-sales engineer with Exalate.

Automatically cloning Epics with their stories to another instance with every field attached you so please, is the bread and butter of sExalate.

The ticket/epic/story (any type) will out-of-the-box be fully bi-directionally syncronized, which means, if a field gets updated on either side, it will automatically update on the other side, you can change this to make it uni-directional if you so please.

Exalate is easy and straightforward to set-up and you can control exactly which data you want to send and/or receive. 

If you would like to see a customized demo of the product, please book a slot with us. 

Cheers

Mathieu Lepoutre

[Mariam Omran]

Hello @Mark Segall ,

I have followed the steps mentioned above, however whenever I open any of my epics and start refreshing for automation rules to run the one I created, it doesn't come up.. any idea why? 

ThankS,

Mariam

[Mark Segall]

Hi @Mariam Omran and welcome to the community!

Because this thread is long and loaded with people. Can you please raise a new question and @mention me?  Be sure to include screenshots of your rule and rule audit log as this will help me investigate the problem.

[Mariam Omran]

hello @Mark Segall  thank you so much.. I have done that now. 

[Arnd Layer]

There is now a rule in the automation library:

"Clone an Epic from one company-managed project to another with all existing issues"

This does not clone Sub-tasks

[Marlene Kegel - codefortynine]

Welcome to the community, @Jose M Gonzalez

I am Marlene from codefortynine. 

Another option would be our Jira cloud app Deep Clone for Jira.

With our app you can clone Epics and larger issue trees and move them to other projects while cloning.

• Simply navigate to the parent issue you want to bulk clone
• Tap on the three-dots menu on the top right of the issue
• Click Deep Clone
• Select "Epic/Tree Clone" and follow the instructions on the Deep Clone dialog.

You can read more about the order of issue keys after cloning in our documentation.

[Mark Williams]

Thank you for the answers. 

Marlene, Deep Clone does not allow me to choose the 50 - 75 projects I need to clone the tickets to. I have to do them individually. Also, the 50 - 75 projects might be 80 -120 next time.

Mark