How to Build a Reusable Jira Template Project on Data Center

If you’re creating 5+ Jira projects per quarter and manually rebuilding the same workflows, roles, and issues every time, you need a proper template project, one that includes both configuration and content. This guide walks you through building one on Jira Server 9.x or Data Center 10.x, maintaining it, and cloning it completely in under 60 seconds.

What You’ll Need

  • Jira Server 9.0–9.6 or Data Center 10.0–10.7.4 (confirm your version at Administration → System Info)
  • Jira administrator permissions (global admin, not just project admin)
  • A source-of-truth project: an existing project whose configuration you want to standardize, or a clear spec of the workflows, roles, and schemes you need
  • The Jira Copy Project Plugin installed (30-day free Data Center trial available; install via Administration → Manage Apps)
  • ~30 minutes for initial template build; ~5 minutes per duplication thereafter

You can skip enterprise migration tools and Groovy scripting for this workflow. The Copy Project Plugin handles full-fidelity duplication (config and content) in a simple five-step process.

Step 1: Create a Dedicated Template Project

Create a new Jira project with a clear naming convention, e.g., key: TMPL, name: “Client Onboarding Template.”

The critical decision here is shared vs. dedicated schemes, and it’s where most admins make their first mistake.

Shared schemes (the default) propagate changes to every project using them. As Atlassian’s documentation states, modifying a shared scheme affects all projects that reference it. That’s fine for org-wide standards but dangerous if your template needs isolated iteration.

Dedicated schemes are copies created specifically for the template. Name them with a TMPL- prefix (e.g., TMPL-Client-Workflow-Scheme). Changes affect only the template until you copy the project.

Use dedicated schemes. This lets you refine workflows and notification rules without breaking live projects. When the Copy Project Plugin duplicates the project, the new project receives its own copies.

Step 2: Configure the Scheme Layer

Walk through each scheme type explicitly; defaults will bite you. Atlassian’s project configuration docs cover the full list.

  1. Workflow Scheme: Map each issue type to the correct workflow. Verify transitions match your team’s actual process.
  2. Issue Type Scheme: Include only issue types this project type uses. Leave “Bug” out of a client onboarding template.
  3. Permission Scheme: Set project role permissions. Pre-assign default groups if your org uses LDAP/AD.
  4. Notification Scheme: Configure notifications for issue creation, assignment, and status changes. This is the scheme most often forgotten during manual setup, and the one that generates the most “why didn’t I get notified?” tickets.
  5. Issue Security Scheme: Set visibility levels if applicable.
  6. Field Configuration Scheme: Set required vs. optional fields. Hide fields that are irrelevant to this project type.

Step 3: Build the Content Layer

This is what separates a useful template from an empty shell. Jira’s native “Create with shared configuration” copies seven scheme types but zero content: no issues, no components, no versions, no subtasks, no attachments. Building this layer is precisely why a plugin is required.

Starter issues: Create the issues every project needs on day one. An agency onboarding template might include: “Kick-off meeting,” “Access provisioning,” “Brand assets collection,” “Project plan review,” “Go-live checklist.”

Subtasks: Add subtasks to complex issues. Under “Access provisioning”: “Create Slack channel,” “Add to GitHub org,” “Provision staging environment.”

Components: Match your standard work breakdown. A dev shop might use “Design,” “Development,” “QA,” “Deployment.”

Versions: Add placeholder milestones: “Phase 1: Discovery,” “Phase 2: Build,” “Phase 3: Launch.” Dates will need updating per project.

Use clear, action-oriented issue summaries. Prefix with category if it helps scanning (e.g., “[Onboarding] Provision staging access”). Write descriptions that explain what needs to happen; the person using this template may not be the person who designed it.

Step 4: Establish a Template Maintenance Process

Without governance, the template drifts and becomes as unreliable as the manual process it replaced.

  • Assign an owner. One person owns the template. Changes go through them.
  • Changelog in the project description. Record date, change, and author. Example: 2026-03-15: Added "Security Review" issue (J. Smith).
  • Quarterly review. Are workflows still accurate? Should issues be added or removed based on recent projects?
  • Lock the template. Restrict issue editing to admins only via the permission scheme.

Step 5: Duplicate the Template with the Copy Project Plugin

  1. Navigate to Projects → Copy Project in the top menu
  2. Select your template project (e.g., TMPL) as the source
  3. Enter the new project name and project key (e.g., “Acme Corp: Q2 Campaign” / ACMEQ2)
  4. Click Copy; the plugin duplicates all configuration schemes, issues, attachments, subtasks, components, and versions
  5. You’re redirected to the new project, fully populated and ready to go

The entire operation takes under 60 seconds.

Verification: Confirm the Copy Is Clean

Spot-check five things after every duplication (under 5 minutes):

  1. Issue count: Quick JQL check: project = ACMEQ2 ORDER BY created
  2. Workflow transitions: Open one issue and click through a full workflow cycle
  3. Role assignments: Confirm defaults at Project Settings → People; add project-specific members
  4. Notification scheme: Verify at Project Settings → Notifications
  5. Attachments: Open an issue with attachments and confirm they’re downloadable

Troubleshooting Common Issues

Problem Cause Fix
“Copy Project” menu not visible Missing admin permissions or plugin disabled Check permissions; verify plugin status in Manage Apps
New project has zero issues Jira version outside supported range, or timeout on large projects Confirm Server 9.0–9.6 or DC 10.0–10.7.4; try a smaller template
Workflow shows as default scheme Template used a shared scheme that was skipped during copy Create a dedicated scheme (see Step 1) and re-copy
Attachments missing Large files may timeout; storage permissions may differ Check limits at Administration → System → Attachments; verify disk space
Role assignments empty Roles referenced individual users instead of groups Use group-based role assignments in the template

Next Steps

  • Scale it: Create multiple templates for different project types: client onboarding, internal initiative, sprint cycle.
  • Refine over time: After 5–10 duplications, prune issues that always get deleted and add ones that always get created manually.

Ready to stop rebuilding projects from scratch? Try the Jira Copy Project Plugin free for 30 days and copy your first project today.