nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

I have Project-A, can I use it as a template to copy for other new Project?

Kristy

my requirement is: I want to save a standard Project template including it's settings(workflow, issuetype, issue fields,permissions, etc) and issues(I don't need to create new issues with same contents in a new project). When create many new projects, people can only revise the content if needed or add new issues or create sub-issues or delete issues if necessary.

Is there a way to make it happen.

In Addition:

I tried Bulk Clone, and found out I can choose 'Rebuild Parent Link' when i want to copy a hierachy (such as Saga and Epic), but it doesn't work if i bulk clone to a new project.

I still do bulk clone testing, hope to figure out if this can solve my question. Hope people who choose this option could give me some advice.

Accepted answers

All comments

Gor Greyan

Hi @Kristy

Welcome to the Atlassian Community!

Yes, this is possible in Jira Data Center, but it depends on what you want to copy.

If you're only looking to reuse the project configuration (workflows, issue types, screens, permission schemes, notification schemes) you can create a new project and associate it with the same schemes used by Project-A.

If you also want the new project to include a set of template issues, epics, tasks, and subtasks that users can modify after creation, Jira doesn't provide this functionality out of the box. In that case, many organizations use Marketplace apps.

Out of curiosity, do you want every new project to start with the same set of template issues, or are you mainly looking to reuse the project configuration?

Kristy

currently I found a way, I am not sure if there are other more easier way.

1. when create a new project, I can select 'create with shared configuration' to copy the template project's settings.

2. I can use Bulk Clone to copy all issues from template project.

yes, i want every new project to start with the same template including the issue.

Gor Greyan

Dear @Kristy

Happy that you could achieve it.

Also, as far as I'm aware, Jira doesn't provide a native one-step option to create a new project that includes both the project configuration and a predefined set of template issues.

Kristy

i think only plugin can provide one-step option.

for the bulk clone, it also has limitation. I want to copy saga-epic to new project, but it can not keep the parent link connection to the new cloned ones, or the epic is still linked with old saga, i have to manually reselect the parent link.

Gabriela - LeanZero

There are really two separate things tangled together in what you're after, and Jira treats them very differently: the project's configuration, and the issues that live inside it.

The configuration side is native. When you create a new company-managed project there's a "Share settings with an existing project" option — point it at Project-A and the new project starts life with the same workflows, issue types, screens, fields, and permission/notification schemes. Three things to know before you rely on it: it's company-managed only (team-managed projects can't share settings), only a Jira admin can create a project this way, and it isn't offered on the Free plan. The one that trips people up is that "share" is literal — the projects point at the same schemes, they're not independent copies. Edit a shared workflow later and it changes for every project sharing it. If you want each project to be able to diverge on its own, you'd copy the schemes rather than share them, or share the setup and only branch the pieces that genuinely need to differ.

The issues are the harder half, because there's no native "clone this project with its issues" button. The usual pattern is to keep Project-A as a master template and copy its issues into each new project as you create it. Two realistic ways to do that: export Project-A's issues to CSV and re-import them into the new project — free, but it won't carry attachments, comments or issue links and you'll remap a couple of fields on the way in — or use a copy/clone app from the Marketplace, where Deep Clone for Jira and Elements Copy & Sync are the two most teams end up on; those bring the whole hierarchy, attachments and links across in one shot. Automation can also clone issues into another project on a trigger, with the same caveat that it skips attachments, links and comments.

So the short of it: reusing the setup is a built-in checkbox, seeding each project with the same starter issues isn't, and whether the app route earns its place comes down to whether those attachments and links matter to your template.

One thing that'd help me point you at the cleanest path — are you on Cloud or Data Center, and roughly how many template issues are we talking about per project?

Trudy P Claspill

@Gabriela - LeanZero

Just a point of clarification:

In your response you talk about Company-managed and Team-managed projects and end asking if the user is using Cloud or Data Center. The tags on their post indicate they are using Data Center.

Screenshot 2026-07-03 at 9.25.32 AM.png

Trudy P Claspill

Hello @Kristy

Welcome to the Atlassian community.

Adding to what the others have said, you could consider setting up Automation Rules to clone the issues after the project is created.

Automation Rules cannot clone the entire issue hierarchy in one rule and maintain the parent/child links. You have do use multiple rules and do something like this:

Rule #1: clones issues at top of hierarchy

- Trigger the rule manually (because Jira DC doesn't have a trigger to detect that a new project has been created)

- Use a Branch: JQL to select the issues at the top level of hierarchy in the original project.

- Clone them into the new project

-- As you clone each one add to the new issue a Label to indicate you will need to look at it in the second rule to clone its children

-- As you clone each one add to the new issue the key of the original issue.

Rule #2: detect an issue created by Rule #1 and clone its children

-- Set this rule to be able to be triggered by the actions of another rule.

- Trigger the rule by issue created

- Add conditions to check for the issue type and the Label you added in Rule #1

- Use a Branch: JQL to select the child issues of the original issue (whose key you recorded in the cloned issue.

- Clone each child issue into the new project

-- As you clone each one add to the new issue a Label to indicate you will need to look at it in the third rule to clone its children

-- As you clone each one add to the new issue the key of the original issue.

Create additional rules like rule #2 to cover each level of the hierarchy.

I've seen this methodology used in Jira Cloud. I have not recreated it myself in a Jira Data Center environment.

Gabriela - LeanZero

@Trudy P Claspill good catch, thanks - the tags do say Data Center, so scratch the Cloud/DC question. On DC the config side is "Create with shared configuration" rather than the company-managed share I described. The issue-copy gap is the same though: a clone leaves Epic Link pointing at the original epic, which is what JSWSERVER-7721 tracks, and a Bulk Change on that leftover value re-points them in one pass per epic.

Matthew Joslin_AppFox_

I believe native Jira Data Center covers half of this: when creating a new project, choose "create with shared configuration" against Project-A to copy its workflows, issue types, screens, and permission/notification schemes, no plugin needed. It won't bring across the issues though. For that you're stuck with Bulk Clone, and as you've found, cloned issues keep their Epic Link pointing at the original epic rather than remapping to the new project (tracked as JSWSERVER-7721). A Bulk Change on the leftover Epic Link value after cloning fixes it in one pass.

One thing worth watching longer-term: "shared configuration" keeps schemes linked, so a later edit to one project ripples to every project sharing it. If they're meant to diverge, the config drift becomes quite hard to catch manually across many template-based projects. Optimizer for Jira is built to surface exactly all of this instance-wide, could be worth worth checking against your specific use case.

Dorota Popowska - Vilisoft

Hi @Kristy ,

Have you had a chance to look at Clone Expert for Jira?

Based on your description, it seems to match what you’re trying to achieve when cloning work items from one project to another. Clone Expert preserves the full hierarchy, so the cloned work items remain linked to each other rather than to the original hierarchy.

You can also review and modify the cloned work items before they’re created, or simply clone them without making any changes.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-data-center

data-center