Copy a Project in Jira Work Management

[Chris Jupin]

I've submitted this feedback to Atlassian but I'd also welcome a workaround from the community: is it possible to create a new project in jira work management based on a previous project? For example, we have quarterly deliverables with roughly 100 tasks that will be the same quarter over quarter and I'd like to be able to save that project as a template and push out that 100 tasks as a blueprint for the next quarter. Anyone got any suggestions?

[Curt Holley]

Hi @Chris Jupin 

Welcome to the Community!

Rather than creating a Project as a template (which can't really be done) I would use Automation for Jira (which is part of Jira Cloud) to push out those 100 tasks.

You could have this set-up to create them upon new project created (ensuring you narrow it down to only on "Business Projects" (aka Jira Work Management projects)

Or (and this might be safer) use the Scheduled trigger.

This way you can have the Automation with the 100 tasks templated set up to run every quarter on each project it is required. Plus, when you create a new project that needs them, copy the automation rule and configure it for the new project, "Run now" and then set-up its quarterly schedule.

This, copy rule and configure for each project technique not only means next project can have a separate quarterly cadence (if required), but also means you are not eating into any multi-project rule execution limitations (especially if you only have Jira Cloud Standard)

Make sense?

Hopefully this is helpful?

Curt

[Sergei Gridnevskii]

Does not make sense if he has 100 tasks - just a waste of time.

[Lewis Cook]

You could do fundamentally what Curt is indicating but I'd probably setup a template project then setup the automation rule to bulk clone the 100 issues using a JQL filter trigger.

Which would certainly be less painful than having to setup multiple rules to create 100 issues.

You could also (if you wanted to have a work management project that doesn't have the templated tasks), just set the rule up to trigger off the creation/closure of a task in the new project. I.E. If when issue created it's summary is "This is a Work Project" then Clone issues found in JQL filter "X,Y,Z" into the current project.

[Curt Holley]

Nice suggestions @Lewis Cook 👍

[Marc - Devoteam]

Hi,

The automation in Jira is also limited to a number of actions you are able to et into a rule. I believe you are only able to set 36 actions in a sing rule.

Cheers,

Marc

[Darryl Lee]

I love Automation but ugh, don't envy the person who has to create a rule or set of rules to create 100 separate tasks. (You could automate rule creation with some JSON hackery but that's another article I have to write.)

But if a big part of the work is just creating tasks, I would propose instead that you export the current set of tasks as a CSV and just import those anew for every new project you create. 

Yes, CSV import is not the sexiest or coolest thing, but it might work for you here. 

And if you did want to automate, I believe Bob Swift's CLI can actually help out here. Ah here we go: https://bobswift.atlassian.net/wiki/spaces/SUPPORT/pages/17563670/How+to+import+Jira+issues+using+CSV+or+SQL

Additionally CLI can also create projects so then, you may be able to get this all working with a nifty shell or BAT script. ;-)

[Annie Ioceva _Nemetschek Bulgaria_]

I would also use  CSV import.Looks as the simplest solution.

Cheers,

Annie 

[Sergei Gridnevskii]

I confirm. Export everything to Excel, clean unneeded fields, save as Unicode CSV and import back.

We prepare test tasks for one of our projects this way. Analytics create tests in Excel, I combine everything in columns Summary and Description, export to CSV and import in Jira. It is pretty much straightforward.

[Curt Holley]

Yeah, I have to agree. CSV in this case, is not a crazy idea at all. 
easier to maintain than a massive (100 task) automation creator or cloner.

[Richter, Mathias (external)]

I'm not related to this product, but a tool like Issue Templates for Jira (Issue Templates for Jira | Atlassian Marketplace) could also make the trick. You can create this or also other sets of tasks and re-use the template again and again. 

[Darryl Lee]

Oh yeah, good call. Issue Templates is a solid product, and a good choice for this if they want to avoid the hassle of CSV imports and are willing to pay for it.

[Mykenna Cepek]

The developer hack in me wonders if there's a way to "adjust" a Jira Cloud backup to just include the one project to be copied, and then "restore" it as a new project.

https://confluence.atlassian.com/cloudkb/how-to-import-only-part-of-a-jira-export-into-jira-cloud-859461966.html

Anyone ever explored that?

[Darryl Lee]

Unfortunately that page describes hacking an backup file down to remove attachments, avatars, etc., and from my experience poking around in the XML files you might even be able to extract only the project and issues you want to clone.

But there's still the problem that upon import, everything gets overwritten in the target instance. :-/

Before importing a backup file to Jira Cloud there are a few important things to note:

• Importing a database backup file containing activeobjects.xml and entities.xml will erase all existing data and replace it with data from your backup. Likewise, importing a media file with the attachments, avatars, or logos directory will overwrite the corresponding data (attachments, avatars, or logos, respectively).
• You can't use this process to import a specific project while maintaining your existing site data. To request the ability to import only specific projects, watch and vote for the Jira ticket: JRACLOUD-31806 - Provide support for "Single Project" migration from Jira Server to Cloud.

I think the "official" way used to be to 1) import the backup file onto a Data Center instance, 2) possibly rename/rekey the project, 3) use Jira Cloud Migration Assistant to migrate just the one project into your instance. Uggggh.

But apparently there is a new feature called "Cloud to Cloud Migration" which looks pretty promising! I wonder if it might even be useful as a way to do testing for new projects/workflows/etc in a Sandbox and then "push" those to Production when ready.

[Anne Saunders]

We're in a completely vanilla cloud instance of Jira.

For a "Project Template", I have set up a few standard spreadsheets for different types of projects, each with a corresponding import config, so that all I have to do is change the project name and key in the spreadsheet to my new project's identifiers, download a CSV of it, then import all of the issues through the Jira Import Manager. 

For tasks that are already inside a project that need to recur weekly/monthly/quarterly/etc., I use my standard import process in tandem with an automation rule. I'd recommend testing with a rule limited to a single project, but these absolutely can be global, assuming your org has buy-in and enough governance and guidance (or a very few admins.)

Each parent recurring issue has label keyed to its recurrence frequency, and each standard frequency has an automation rule to create new clones of the parent issue on a schedule using the When: Scheduled component and basic scheduling (rather than a CRON.) I use a JQL search based on the label and on the parent issue's key being one of the original set from the template (<= the highest key value in its template).

I use smart values inside the Then: Clone issue into component to append the "when" to the new issue's summary. Basically, if the initial task's summary is "Run Monthly Report", and there's a label of "Monthly", the smart values " {{issue.summary}} - {{now.format("MMM yyyy")}}  " make the fresh task for last month have the summary "Run Monthly Report - October 2021"