Being able to create a new Jira project from a template one is a key requirement going forward.  We badly need this! Even being able to copy the issue tickets from a basic template Jira board but with no dependency links would be helpful as a first step. 

This would be so helpful. I take my time to customize by boards and projects and hate having to do it all over again for the next project. Fully support the development of this feature. 

Any updates on this?

Is there any update on this?

Being able to re-use a project template including the full ticket structure is a pretty basic need that many Jira users will benefit from.

Create a Project through template is a great feature in Jira,

we have noticed that when we create a new project through template it is not creating project specific new context to add a project specific dropdowns, and also we have created some behaviors as a part of automations and we expect our new project get mapped to it automatically when we create project through template,

Please let us know whether we have any option to achieve above features?

We are using Jira Data Center.

Thanks,

Santhosh

Future Consideration? It's been 15+ years. Highly unlikely!!!

I would love to have the functionality to copy projects on a hosted environment, for our business and continuity this would make life a lot easier, I'm having to create the exact same project on our instance of Jira for another client. It would be great to look into this as I do believe there should be a huge demand for this functionality to exist.

This should be simple to do and a basic feature for any tool like this. We do a lot of projects that are similar and need to copy a complete project with issues and everything to limit the workload and limit errors in issue creation and project setup.

If it's not revenue protection, what then keeps Atlassian from implementing massively requested and honestly naturally expected features?

Any other professional product that does not rely on Plugins would include such a feature.

We need the possibility to create events with pre-configured Kanban Boards and pre-configured Tasks. Is this possible with one of the Add-ons mentioned above? Disappointing, that this basic functionality isn't standard in JIRA...

Forgot to mention: We use the cloud version, so most of the add-ons don't work for us.

Thanks, but I shouldn't have to pay thousands more for an addon just to provide a simple feature which should be part of the base product.

Just an FYI, the power scripts app can create issue template automation and solve this use case. You can bulk copy projects, issues, attachments and even create a template of issues to launch and reuse quickly. (more info)

As a new Jira admin I'm constantly facing with more and more basic functions of administration that are not built into Jira. 

In our industry automation is not optional so making "addons" like JIRACLI and scriptrunner (groovy) so costly and not built-in is huge disappointment.

As a new user I feel like Atlassian are focused on writing "addons" instead of having features as built-in capabilities.

As an employee of the vendor in question... I don't think Atlassian are not implementing this in order to protect our revenue. I don't have much of an insight into Atlassian, but very frequently they will implement features provided by plugins, often just months after it appears in a plugin.

If they didn't want to step on our toes they would not be working on JRASERVER-25640 (find issues by their linked issues), which will hurt our revenues much more than if they supported project schemes.

it is highly doubtful that Atlassian would step on that vendor's toes by adding that functionality into native Jira

Why? Because customers should have to pay thousands more per year to a 3rd party to do this basic feature? Or because Atlassian gets a cut of the sales for that addon so Atlassian actually gets more money by not implementing this?

Hello world.

Since the proven ScriptRunner for Jira plugin already has the capability to quickly (less than 1 minute) do this work, it is highly doubtful that Atlassian would step on that vendor's toes by adding that functionality into native JIRA.  Thus, I am removing my Watcher selection for this nearly 13 year old Suggestion issue.

15 years??  I need this now. Goal is to create a template for LeSS. It would be ideal to copy the structure from an existing project rather than reinventing the wheel. Please. 

Hi, we administer Jira for more than 300 projects. And it would be really more convenient if you could add functionality with creating projects and schemes template. We would appreciate to see this feature in the following version of JIRA, since now it's time consuming to "play" with Jira each time we should create new unique project. Thank you!

In the studio i work we are looking for a way to create a Project Template (or modify an existing one), so when we create a new project it already has out default permissions, workflows, issues types, screen, fields, and notification setup.  We know that it only take s few minutes to configure this but it would may life so much easier. We were kind of surprised this option didn't already exist. 

Fair enough see what you mean. Personally I like that as gives option to diverge project from clone if needs be.

To handle your sort of issue, I don't change the Issue Type Scheme to another one, but edit it instead so it is reflected in all projects using that scheme.

Seems there's at least three requirements here depending what people want and seems from this thread there are different people who want some of all three of these:

1. Clone a project and create independent copies of all project config schemes.
2. Clone a project and ensure clones are always kept in sync to project config schemes.
3. Clone a project with initial shared config but allow them to diverge if schemes are changed (this functionality is there with "Create with Shared Configutation").

Plus with the other caveat that it should be user friendly and obvious how to pick these three and what they all mean. Complicated one for Atlassian to solve...

@barry.pollard The "Create with Shared Configuration" is very misleading. It does NOT do what i explained. After the project is created, there is no direct link between the configuration of each project. So, if you change the Issue Type Scheme to a different scheme on the original project, that same change does not occur on the new project. Therefore the configuration of the project is NOT shared. It is only sharing the separate schemes selected for each individual configuration within the project.

Please look at the documentation at https://confluence.atlassian.com/adminjiraserver070/defining-a-project-749382822.html as well as a suggestion to change the name of "Create with Shared Configuration" here: https://jira.atlassian.com/browse/JRA-45840

Some of the pain in changing schemes in projects have been alleviated in the past when they changed what modifications can be done to a workflow scheme, but the need is still there to keep many projects in sync with all the same schemes.

"Create with Shared configuration" unfortunately is at least for me for the majority of projects I have to create NO real alternative to the original and suitable clone functionality. I wonder why this functionality has not been updated by Atlassian for the usage in Jira 7.x.

@abarylak "Create with Shared configuration" sounds exactly like what you want. Are you sure you understand how this works? The config is shared even after the project is created - there is no copy per project.

This actually works very well for me and largely negates the need for this request for me. Personally I hate the way that JIRA creates project specific config each time you create a new project. Gets very messy and duplicates a lot of identical or near identical workflows, screens, fields...etc. and loses any work you've put into workflows. So shared config for me all the way and I think this should be encouraged more in JIRA as the default to use, rather than hidden at the bottom of the screen.

However I can sort of see the need for @scott.soltero wish to be able to clone in some cases, so that if someone is intending to change the workflow (for example) just for that project then it doesn't affect other projects. But to do that I personally prefer to create with shared config initially, and then change Workflows/Screens/Fields to a project specific one if needed. And copying a workflow for example, and then updating the project to use that copy, makes this relatively easy (though admittedly a two step process).

@Pete W, the "Create with Shared configuration" is what I want to avoid. What I need is the ability to create templates that deploy unique instances of each scheme. That way I could create the 3-4 base line templates I need and deploy projects with only minor tweaks.

No, that is not what we want. That only creates the project from a template, but is then completely separately managed. It is the same as using the ScriptRunner built-in script to copy a project to a new project.

What we are looking for is a way to give a bunch of projects a specific scheme, so that we can apply workflow/notification/permission/issue type/etc schemes to the project scheme, and then any project which uses that scheme also inherits the same changes. Basically so we can ensure a specific group of projects always has the same configuration and behaves in the same way. It causes a lot of user confusion when a certain issue type behaves in different ways between projects, or if a user gets a notification for something in one project but not in another. They get really confused and cause additional administrative overhead to deal with questions around these inconsistencies.

Hopefully this issue will gain some traction sometime before i retire... i'm only 33

In my create new project there's a link at the bottom that says "Create with shared configuration"

Is this what some of you want? did the trick for me.

We just upgraded from JIRA 6.3.15 to JIRA 7.1.4, and I strongly concur with the previous sentiments on creating new templated projects to avoid having to delete lots of unneeded and tailored stuff (workflow scheme, workflows, issue type screen scheme, screen scheme, screens, etc.). Allowing an admin to copy a project would be a much more efficient strategy.

@David Skreiner vote +1
copying the schemes is a truly horrible!

Could you try not always selling add-ons as "solutions" or workarounds to JIRA issues?
While you're at it, please also make it so JIRA no longer creates a dozen copies of default schemes whenever one creates a project.

Adding my vote to clone a project, this is a huge time saving feature that will aid my team and I.

How is this not a priority?

Because Atlassian doesn't care. There are dozens of tickets just like this one with huge numbers of votes, comments, and customer support which have been ignored by Atlassian for about a decade. They just don't care.

–
Join the Atlassian Doesn't Care Team. Change your profile name to Atlassian Doesn't Care today!

JIRA, please look over the 100+ comments and the 500+ votes on this ticket and realize that you need to deliver a solution to your paying customers. This feature was requested 9 years ago. This is one of the most voted on suggestions. (14th most voted on at the time I wrote this) How is this not a priority?

I completely understand TJ. We are actually have our own implementation of what you describe above, creating JIRA Projects out of templates, elements, Confluence integration, Source Code (SVN or Bitbucket), Maven and more integration. Just consider it a one stop portal for ALM tools with integration built-in based on what your project need). I did not realize there's some tool out there that is pricing this much for the same functionality.

@Gabrielle, the automation script the company provides does more than simply copy projects (it has some very nice features to allow selecting pre-defined elements and creating projects + confluence space with page tree and content, etc). It's a great solution, but not for money they want to charge.

The point of the matter is that it's stings to be told you must pay more to get greater functionality after already paying so much.

Russ said it perfectly:

...whilst it is obviously desirable to have a community of developers adding functional richness to a start-up product, eventually the people who pay enterprise software prices will start to expect continuous functional improvement in their SaaS product.

TJ, that does not seem right. Copying an existing JIRA Project costs 10k now? I should be living in NY then!

+1 to the sentiments shared today.

I voted for this issue shortly after we adopted Atlassian, having left a system that does provide project templates.. that was almost three years ago.

Now we have a 10 page 'guide to creating projects' for our sales and project management teams, simply to describe how to copy pages in confluence to set up information structure, manually create issues from each page, create the project board with our designated columns, etc etc.

I found a company who seemed to have found a way to automate this, and they wanted a measly $18k to implement it for us, or they were willing to let us use their code for a discounted $10k.... neither option being anywhere near affordable for us, especially in light of the thousands we pay per month to use Atlassian's solutions.

This is the culture that Atlassian has created, and seemingly continues to promote, and it's pretty sad to see.

I agree with Russ.
And sadly, it doesn't stop them of wasting effort in changing the licensing scheme every 2 years or so, increase by thousands the renewal fee while pushing missing feature toward the Marketplace.

Atlassian will indeed have to make a choice: Lower the core price and have customer rely on expensive plugin in the Marketplace, or start to actually listen to customer and start fixing / adding missing core features.

After nearly 8 years with Atlassian, I've got the feeling they're more inclined in creating bait features, adding features to attract new customers, but doing nothing to the customers who are integrated into Atlassian products who can't really look for an alternative without breaking their whole system or losing historical data.

Completely agree with Kevin's comments above.

JIRA have given themselves a bit of a problem with the marketplace; whilst it is obviously desirable to have a community of developers adding functional richness to a start-up product, eventually the people who pay enterprise software prices will start to expect continuous functional improvement in their SaaS product.

I cannot recall a single idea that I have supported being incorporated into the product in the two years we have been using this system; I can recall many ideas that have been dismissed by the product team with a note to say that there is someone willing to take ever more money from us to supply what is obviously a very popular enhancement.

Atlassian will need to make a choice on this at some point, and decide if it is the marketplace partners or the paying consumers who are the priority for them.

(Speaking as a fan and evangalist for Confluence+Jira)

Project curation should NOT be an add on! It should be a core offering, if Atlassian fancy themselves as something for the enterprise instead of for teeny teams.
Judging by their IPO success, I hope they do acknowledge this and start maturing their product PDQ.

+1 to Scott's comment

The problem with the options listed for add-ons is that none are available for the Cloud offering. Cloud users also need the ability to copy or clone projects so we do not have to reconfigure the project each time one is created.

+1 to previous comments.

+1 to Chantale's comment. The implementation is a welcomed step in the right direction, but only partially provides a 'workaround'. This offering doesn't even create boards as they exist in the 'Create from shared configuration' copied project, plus all that was mentioned in Chantale's comments.

Only very partially. It is a proper workaround I suppose but the bigger the team the riskier it is. Say I make a base project that all software development project should start from. One may think it's simply a standard project and modify it which means that the next time we will want to add a project our base is destroyed. If it was a project template it would be clearer what the intent is and I would presume only JIRA administrators with global permissions could modify it. Also, the access to a project template is clearer. It does not require specific training as how and when to use and for which project kind.

So yes partially fixed but the custom project template would be better and easier and have faster access.

Isn't this partially fixed with "Create from shared configuration" since Jira 7?

this feature would be great to sync configuration between a test instance and a production instance

I would just like to re-iterate my company's wish for this feature. I know that the top comment names four plugins that can be used for this purpose, however due to the inactivity on this issue these plugins have become increasingly more expensive - in fact the one we use recently increased its price by SEVEN fold. We would like to use JIRA more widely in the company and start using Ondemand instances as well, but this issue more than any other is holding us back.

With the new "Project Types" introduced in JIRA 7.0, may I suggest the time is ripe to introduce Project Templates in 7.1.

Edit: Incidentally we are now proceeding with a workaround as follows; We will stop using our current plugin (too expensive) and create a template project with all roles removed except for our project creators in the Manager role. Thus our regular users should not see the template project(s). It does mean that our project creators will still need an explicit work instruction to use the small "Create with shared configuration" hyperlink provided in JIRA 7, to select the correct template project, and to re-add the roles they desire to the project, and they will need to be careful not to modify the template project by mistake. While not ideal this is still more manageable than training them to select every scheme correctly by hand.

You have a point. However we deployed our JIRA as a Service so our users can create projects theirselves without any help from our team (We already have 1,200 JIRA Projects, 21,000 users and still growing) so this feature is nice to have.

Right now, we have a front end portal that let our users create their JIRA Projects with "template choices" on it (SDLC Template, Agile Template, CI Project, etc...) to give them this feature.

While it's an inconvenience, I've found that (as long as you have the 'Jira Default Schemes' reenabled) you can create a new project then assign all the correct schemes in around 5mins. Which isn't an unreasonable amount of time to create a new project. Given the customisation involved (new key, avatar, URL) a template engine would probably only save 3-4mins for each project, which for our company would be ~30-60mins per year. Small change in the grand scheme of things...

I'm another user that loves most of JIRA (Cloud), but everyone in my team hates that copying/cloning projects isn't a standard feature as well. I use Bitbucket for repositories; not exactly sure why you can't do something similar to their repository cloning and simply rename it.

We're still evaluating JIRA, and this issue alone has the potential to skip JIRA altogether. Is there really no other solution other than Script Runner that's developed in the past few months?

@Dmitry, the way I've achieved this in my Cloud instance is by requesting the setting be reverted by the Atlassian support team (as mentioned in CLOUD-7806 / JRA-43415). I now have the normal create options which includes the 'Jira Default Schemes' option which uses the schemes I already have defined.

You can also use Bob Swift add-ons to automate the process:

• Use the JIRA Command Line Interface (CLI) add-on as shown in this recipe to copy the project. (This works for JIRA Server and JIRA Cloud)
• You can further refine the technique to allow end-users to create templatized JIRA projects by using the Run Self-Service Reports for Confluence add-on to build a form through which users can select which "template" on which to base their new project, similar to how these recipes demonstrate. (This works for Confluence Server.)

For us (download version of JIRA), the workaround that speeds up things a lot, is this one:

• create a template project - with settings as you wish, such a the schemes of your preference, etc., probably with empty Roles, since those are being taken care of within the project. Perhaps also create multiple templates (eg, we have one for bug tracking and one of Agile dev). Also, probably the template project lead will be yourself.
• install Script Runner plugin, create a bookmark (eg in your browser) to the Copy Project function of the plugin.
• any time a new project is needed, click the bookmark = go to the Copy Project page, select the template, fill in new Key and Project name, Run....
• finally, change the project lead to the real one and off the project goes.

Since this seems so simple and a huge improvement, also I'm one of probably many wondering why this isn't a standard possibility in JIRA.

@andrew so is there a way to create a project without any duplicate rubbish?

@Andrew Good to know, thanks!

@Dmitry Pashkevich, sorry to confirm but the 'Software Development' also creates rubbish throughout the system instead of using the preconfigured defaults. From what I can see CLOUD-7806 covers bringing the 'Classic Workflow' back for OD instances by logging a request with the Atlassian support team.