How to Copy a Jira Project with Issues and Attachments in 5 Steps
If you’ve ever created a new Jira project using “Create with shared configuration” and been greeted by an empty project (correct schemes, zero content), you’ve hit the most persistent frustration in Jira administration. Atlassian Community threads dating back to 2017 document the same problem: native Jira Server and Data Center can share configuration schemes between projects but lack any mechanism to copy issues, attachments, subtasks, components, or versions. Those are the actual content that makes a template project useful.
This guide documents exactly what native Jira copies and what it drops, then walks through the Jira Copy Project Plugin’s five-step workflow that copies configuration and content in a single operation, along with honest coverage of what it misses.
What “Create with Shared Configuration” Actually Copies
The confusion starts with the name. “Shared configuration” sounds like it copies a project’s setup into a new one. It does something different. As Atlassian Community expert Nic Brough clarified, the option “sets the new project to use the schemes the one you choose to share with is currently using.” It points the new project at the same schemes rather than cloning them. Change a shared workflow scheme later, and every project using it changes too.
Community Champion John Funk put it simply: “It basically is just going to copy schemes.” And even that is generous; he confirmed that components and versions are skipped despite what some Atlassian training materials suggest.
The result: you get a project shell with correct permission, workflow, and notification schemes, but zero issues, zero attachments, no subtasks, no components, no versions. One user on the Atlassian Community called this “a severe oversight.” For teams maintaining template projects with pre-loaded deliverables, that’s only half the job done.
What Each Method Actually Copies
| Project Element | Native “Shared Configuration” | CSV Export/Import Workaround | Jira Copy Project Plugin |
|---|---|---|---|
| Workflow Scheme | ✅ Shared (linked, not independent) | ❌ Not applicable | ✅ Copied (independent) |
| Permission Scheme | ✅ Shared (linked) | ❌ Not applicable | ✅ Copied |
| Notification Scheme | ✅ Shared (linked) | ❌ Not applicable | ✅ Copied |
| Issue Type Scheme | ✅ Shared (linked) | ❌ Not applicable | ✅ Copied |
| Project Roles | ✅ Shared | ❌ Not applicable | ✅ Copied |
| Issues | ❌ Skipped | ⚠️ Partial (loses metadata) | ✅ Copied |
| Attachments | ❌ Skipped | ❌ Not carried in CSV | ✅ Copied |
| Subtasks | ❌ Skipped | ⚠️ Requires manual re-linking | ✅ Copied |
| Components | ❌ Skipped | ❌ Must recreate manually | ✅ Copied |
| Versions | ❌ Skipped | ❌ Must recreate manually | ✅ Copied |
| Boards (Scrum/Kanban) | ❌ Skipped | ❌ Not applicable | ❌ Skipped |
| Custom Field Contexts | ❌ Unadjusted | ❌ Not applicable | ❌ Unadjusted |
| Dashboards/Filters | ❌ Skipped | ❌ Not applicable | ❌ Skipped |
The five elements that matter most for template-based project creation (issues, attachments, subtasks, components, and versions) are the exact five that native Jira drops. The community thread on cloning projects and issues has been active since March 2017, with one commenter noting: “So many posts on the subject, 700 votes for the issue in support, and still no updates.”
Jira’s shared configuration is useful for its intended purpose: standardizing schemes across projects. It just falls short of project duplication.
How the Jira Copy Project Plugin’s 5-Step Workflow Works
The Jira Copy Project Plugin from Lane Technology fills the content gap with a streamlined UI workflow. No scripting, no CSV juggling, no external tools.
Prerequisites: Jira Administrator global permission, Jira Server 9.0–9.6 or Data Center 10.0–10.7.4, and the plugin installed from the Atlassian Marketplace (a 30-day free trial is available).
Step 1: Navigate to Projects, Then Copy Project
After installation, a “Copy Project” option appears in the top navigation bar under the Projects menu. Only users with Jira Administrator permissions see this option, which keeps project creation controlled without extra permission configuration.
Step 2: Select the Source Project
Choose the project you want to duplicate from a dropdown of all projects on the instance.
Practical tip: Maintain a dedicated template project (e.g., “CLIENT-TEMPLATE”) that serves as your gold standard. Keep it updated with your current workflow, standard issues, and attachments. Never assign real work to it.
Step 3: Enter the New Project Details
Provide the new project’s name, project key (the prefix for issue keys, e.g., ACME), and optionally a description. The project key must be unique across the instance; the plugin validates this before allowing you to proceed.
Step 4: Click Copy and Wait
The plugin duplicates all supported elements in a single operation: workflows, roles, notification schemes, issues (with attachments), components, versions, and subtasks. Behind the scenes, it creates independent copies of schemes (not shared references like native Jira), re-keys all issues to the new project key, and copies attachment files on disk. Processing time depends on project size; a 25-issue template project typically completes in under a minute.
Step 5: Verify the New Project
The plugin redirects you to the newly created project. Run through this verification checklist:
- Issue count matches the source project
- Attachments are accessible on key issues
- Subtask parent-child relationships are intact
- Components and versions are present and correctly named
- Workflow transitions work correctly on a test issue
- Notification scheme fires correctly (trigger a test transition)
The entire process, from clicking “Copy Project” to verifying the result, takes under two minutes for a typical template project.
Agency Client Onboarding: 2 Minutes vs. 2.5 Hours
Consider a 40-person marketing agency running Jira Data Center to manage client engagements. They maintain a template project (“CLIENT-TEMPLATE”) containing:
- 25 issues covering standard deliverables (brand audit, content calendar, social media setup, campaign briefs, analytics setup)
- 2–3 attachments per issue (brief documents, checklists, reference files; roughly 60 files total)
- 6 components (Strategy, Creative, Content, Social, Analytics, Admin)
- 4 versions (Discovery, Phase 1, Phase 2, Ongoing)
- Subtask trees for multi-step deliverables
The manual process (before the plugin):
- Create new project with shared configuration (5 min)
- Export 25 issues to CSV from the template project (10 min)
- Import CSV into new project, troubleshoot field mapping errors (20 min)
- Discover attachments didn’t transfer; manually download and re-upload 60+ files (45 min)
- Recreate 6 components manually (10 min)
- Recreate 4 versions manually (5 min)
- Verify subtask relationships, find they’re broken, manually re-link (30 min)
- Spot-check notification scheme, realize it’s shared with the template, fix it (15 min)
Total: approximately 2.5 hours, assuming nothing else goes wrong.
The plugin process:
Projects → Copy Project → Select CLIENT-TEMPLATE → Enter “ACME Corp” / “ACME” → Copy. Total: approximately 2 minutes.
At 8 new client projects per quarter, the manual approach consumes 20 hours (a full work week) of admin time per quarter. For a solo Jira admin with a backlog of other maintenance tasks, that’s time that directly delays the billable client work the project was created to support.
What the Plugin Skips
Every tool has boundaries. Here’s where this one stops.
| Element | Copied? | Workaround |
|---|---|---|
| Custom field configurations/contexts | ❌ | Verify custom fields are globally scoped, or manually add project contexts |
| Scrum/Kanban boards | ❌ | Create a new board and associate it with the copied project |
| Sprint data | ❌ | Sprints are board-level; create new sprints in the new project |
| Dashboards and saved filters | ❌ | Manually duplicate or rebuild using JQL |
| Automation rules | ❌ | Manually recreate or use automation export/import |
| Issue links to other projects | ❌ | Cross-project links reference source project issues |
| JSM queues, SLAs, request types | ❌ | Plugin targets Jira Software, not Jira Service Management |
Operational constraints:
- All-or-nothing duplication. You can’t copy only issues without config, or only specific issue types. If you need selective copying, look elsewhere.
- No API or CLI. The operation is UI-only. You can’t script it or trigger it from a CI/CD pipeline. For programmatic project creation, ScriptRunner with Groovy scripting handles that use case.
- No cross-instance copying. The plugin operates within a single Jira instance. For dev-to-prod promotion or instance migration, Project Configurator covers that scenario.
- Single project at a time. No batch operations for duplicating multiple projects simultaneously.
- No Jira Cloud support. The plugin supports Jira Server 9.0–9.6 and Data Center 10.0–10.7.4 only.
Edge case worth noting: The plugin’s behavior when a scheme with the same name already exists on the instance is undocumented. Test with a non-critical project first; the 30-day trial makes this easy to do risk-free.
When to Use What
Different problems call for different tools.
| Your Scenario | Best Tool | Why |
|---|---|---|
| Empty project with correct schemes, no content needed | Native “Create with shared configuration” | Free, built-in, sufficient for scheme-only setup |
| Full project replica: config, issues, attachments, components, versions | Jira Copy Project Plugin | Copies everything in one operation; simple UI; low cost; no scripting |
| Cross-instance migration or environment promotion | Project Configurator (Appfire) | Purpose-built for multi-environment management; starts at $1,450/yr |
| Scripted/automated project creation in a CI/CD pipeline | ScriptRunner (Adaptavist) | Groovy-based API access; starts at ~$5,000/yr; requires developer skills |
| Clone individual issues into an existing project | Clone Plus (Appfire) | Issue-level cloning with field customization |
The Jira Copy Project Plugin sits between “free but incomplete” (native Jira) and “powerful but expensive” (Project Configurator at $1,450–$86,000/yr, ScriptRunner at $5,000+/yr). If your need is straightforward duplication of a template project with all its content, you don’t need a scripting platform or a migration tool. As Nic Brough’s accepted answer put it: “Natively, you can’t; JIRA will let you set up a project with the same schemes, but cloning all the issues is simply not in there.” The plugin puts it in there.
An honest note on market position: With 72 installs and a small vendor behind it (Lane Technology, Franklin, TN), this is an early-stage product. The 30-day free trial lets you validate it in your specific environment (your data, your schemes, your edge cases) before committing. If vendor scale is non-negotiable for your procurement process, the enterprise alternatives may be more appropriate despite the higher cost.
One more consideration: Atlassian has announced Data Center end-of-life for March 2029, with new DC subscriptions ending March 2026. If you’re on DC today, you’ll likely be running it for another 2–3 years. A low-cost plugin that saves 20+ hours per quarter pays for itself long before that window closes.
Install the 30-day free trial from the Atlassian Marketplace and copy your first project in under two minutes. If it saves you no time on the first use, you’ve lost nothing.