Symptoms

• New project has zero issues (empty shell with correct schemes)
• Issues exist but attachments show “preview unavailable” or are missing
• Subtasks missing; only parent issues copied
• Components and versions lists are empty
• Workflow transitions fail with “Validation failed”
• Notification emails not firing for the new project
• Project roles exist but have no members assigned

Fixes (Most Common First)

Fix 1: You Used “Create with Shared Configuration,” Which Copies Only Schemes

Diagnosis: New project has correct schemes but zero issues, no components, no versions, and empty role assignments.

This is expected behavior. Native shared configuration copies schemes only:

What most admins miss: shared configuration creates shared schemes. Changing a workflow in the source project changes it in the copy too. If you need independent schemes, create and reassign new ones manually.

Fix: There is no native way to retroactively add issues and attachments. Use CSV export/import for issues (see Fix 2 caveats) or a plugin that copies config and content together (see Prevention below).

Verify: Check the new project’s Issues tab, Components, Versions, and Project Settings → People.

Fix 2: You Used CSV Import and Subtasks or Attachments Are Missing

Diagnosis: Issues exist but subtasks appear as standalone issues, and attachments failed to transfer.

Why: CSV import can’t preserve parent-child relationships in one pass. Import parents first, get new keys, then reimport subtasks with updated Parent IDs. Attachments require publicly accessible URLs; on-prem filesystem attachments won’t transfer.

Fix:

1. Subtasks: Re-export from source. Update the Parent ID column with new parent keys. Reimport.
2. Attachments: Re-attach manually, or use the REST API (POST /rest/api/2/issue/{issueKey}/attachments) to copy programmatically.

Verify with JQL:

• Subtasks: project = NEWKEY AND issuetype in subTaskIssueTypes()
• Missing attachments: project = NEWKEY AND attachments is EMPTY

Fix 3: Workflow Transitions Fail with “Validation Failed”

Causes (most likely first):

1. Duplicate workflow name. Check Administration → Issues → Workflows for name conflicts. Rename or remove the duplicate.
2. Create transition validators. Validators block issue creation when required fields are empty. Edit the workflow → Create transition → temporarily remove required-field validators.
3. Inactive workflow. Check for “Inactive” status under Workflows and publish the draft scheme.

Verify: Run Administration → System → Integrity Checker; select workflow checks and fix flagged issues.

Fix 4: Notification Scheme Assigned but No Emails

Cause: The scheme targets project role-based recipients (“Developers,” “Project Lead”), but role memberships are empty in the new project. Notifications fire to nobody.

Fix: Go to Project Settings → People. Populate each role. Cross-reference the source project’s assignments.

Verify: Assign a test issue, then check Administration → System → Mail Queue for recipients.

Still Stuck?

1. Gather your Jira version, copy method used, and exact error messages.
2. Run the full Integrity Checker: Administration → System → Integrity Checker; select all checks.
3. Contact Atlassian Support for Server/DC issues, or the plugin vendor if using a third-party tool.

Prevent Incomplete Copies

Choose your copy method before the next project:

If you need config and content copied in a single operation, the Jira Copy Project Plugin handles this in five clicks for Jira Server 9.x and Data Center 10.x. A 30-day free trial is available.

If that sounds familiar, this guide walks you through evaluating whether the Jira Copy Project Plugin covers your needs, running a parallel test alongside ScriptRunner, and making a confident switch (or deciding ScriptRunner is still the right tool). The whole evaluation takes one to three days. The 30-day free trial means zero financial risk.

Is This Guide for You? A 60-Second Decision Filter

This guide IS for you if:

• You use ScriptRunner’s Copy Project through the UI (Admin → Built-in Scripts → Copy Project)
• You don’t trigger project copies via REST endpoints, post-functions, or scheduled scripts
• You don’t rely on ScriptRunner’s other capabilities (listeners, behaviours, escalation services, script console) or you have those needs covered by other tools
• You’re paying thousands per year for ScriptRunner DC and questioning the ROI for a single feature
• You’ve hit one of the known Copy Project bugs: projects inaccessible after copy, failures during issue cloning, or checkbox UI breaks after Jira upgrades

This guide is NOT for you if:

• You trigger project copies programmatically via ScriptRunner’s REST endpoint or Groovy API
• You use Copy Project inside post-functions or automated workflows
• You need JSM-specific copying (request types, queues, SLAs); the Copy Project Plugin doesn’t handle these
• You need selective element copying (e.g., copy issues but skip versions); the plugin copies everything as a single operation
• You rely heavily on ScriptRunner for other admin tasks beyond Copy Project

If more than one item in the second list applies, ScriptRunner is still the right tool. Close this tab and carry on.

ScriptRunner Copy Project Bugs This Migration Sidesteps

These are community-verified issues with ScriptRunner’s built-in Copy Project script, each documented in Atlassian Community threads.

Project created but inaccessible

On Jira Data Center 9.12.13, ScriptRunner’s CopyProject creates the project successfully (it appears in the REST API at /rest/api/2/project) but getProjectObjByKey() returns NULL. The project is invisible in the Jira UI until an admin manually edits a project attribute in the admin panel or calls ComponentAccessor.getProjectManager().refresh() to force a cache sync. Every copied project requires this manual intervention. (Atlassian Community)

NullPointerException during issue copying

When copying projects with issues, a java.lang.NullPointerException fires in DefaultWatcherManager.isWatching() during the copyWatchers() step. The copy fails mid-process, potentially leaving a partially-copied project with some issues transferred and others missing. The only community guidance: contact Adaptavist support. (Atlassian Community)

Checkbox UI breaks after Jira upgrades

After Jira version upgrades, the Copy Project built-in script’s checkbox interface stops responding; admins can’t select which elements to copy. The issue was tracked as SRJIRA-3827. Copy Project becomes completely unusable until Adaptavist releases a compatibility patch. (Atlassian Community)

Silent issue-cloning failures from post-functions

When Copy Project is triggered from a post-function, the target project is created but issues don’t clone. No errors appear in logs. The script executes without exceptions but silently skips issue copying, even though the same code works correctly from ScriptRunner’s console. (Atlassian Developer Community)

Why the Copy Project Plugin avoids these

The Jira Copy Project Plugin is a purpose-built tool with a single operation, not a general scripting platform that exposes project copying as one of dozens of built-in scripts. It has no Groovy runtime, no cache synchronization step, and no UI framework that breaks when Jira’s frontend changes. The plugin is tested against specific Jira Data Center versions (10.0.0 through 10.7.4) and performs the copy as a native Jira operation.

Feature Mapping: ScriptRunner Copy Project → Jira Copy Project Plugin

This table translates every ScriptRunner Copy Project option to the plugin’s equivalent behavior. The ❌ rows matter as much as the ✅ rows.

If the rows marked ❌ describe features you actively use, ScriptRunner is still the right tool. This migration makes sense when your workflow is: select source project, check the boxes for schemes, roles, versions, components, and issues, click copy. That core duplication workflow maps 1:1.

The Cost Case: ScriptRunner vs. a Dedicated Plugin

ScriptRunner for Jira is developed by Adaptavist. Data Center annual subscriptions scale by user count, starting at roughly $500/yr for small teams and climbing into the thousands for mid-size organizations (500+ users). For a 500-user Data Center instance, annual ScriptRunner licensing represents a significant line item.

The Jira Copy Project Plugin is estimated at under $500/yr on the Atlassian Marketplace, with a 30-day free trial for Data Center.

Break-even math

If your ScriptRunner renewal runs several thousand dollars annually and Copy Project is the sole feature justifying that cost, the savings from switching to a sub-$500 dedicated plugin compound quickly over the remaining Data Center lifespan through March 2029.

Important caveat: This math only works if Copy Project is the sole reason you’re renewing ScriptRunner. If you use listeners, behaviours, script console, or any other capability, the savings calculation changes entirely.

Three decision paths

• Drop ScriptRunner entirely. Only if Copy Project is your sole use case. Audit first: Admin → ScriptRunner → Script Registry to see what’s active.
• Keep ScriptRunner + add Copy Project Plugin. If you use other ScriptRunner features but want reliable project copying. The two plugins run independently.
• Stay with ScriptRunner alone. If you need programmatic triggers, JSM copying, or selective element copying.

Step-by-Step: Running a Parallel Test

Before you start

• Confirm your Jira version: the Copy Project Plugin supports Data Center 10.0.0 through 10.7.4 (and Server 9.0.0 through 9.6.0)
• Identify a non-production source project with representative complexity: multiple workflows, role assignments, 50 to 200 issues with attachments, components, and versions
• Ensure you have Jira admin access
• Budget 1 to 2 hours for the test; results comparison takes another 30 to 60 minutes

Step 1: Install the Copy Project Plugin trial

Navigate to Jira Admin → Manage Apps → Find New Apps. Search “Jira Copy Project Plugin” by Lane Technology. Install the 30-day Data Center trial. No restart required. No configuration needed.

Installing alongside ScriptRunner is safe; the plugins operate independently.

Step 2: Copy the same project with both tools

With ScriptRunner: Admin → Built-in Scripts → Copy Project. Select your source project. Check all standard boxes (versions, components, issues/attachments). Create as TEST-SR-[ProjectKey].

With Copy Project Plugin: Projects → Copy Project. Enter source project, new name TEST-CP-[ProjectKey], new key. Follow the five-step wizard and click Copy.

Step 3: Compare the output

Use this checklist to compare both copies against each other and against the source:

Navigate to Project Settings on each copy and compare scheme assignments side by side. Use JQL (project = "TEST-SR-X" and project = "TEST-CP-X") to count issues and subtasks. Spot-check 5 to 10 issues for attachment integrity and field values.

Step 4: Make your decision

If the plugin copy matches or exceeds ScriptRunner’s output, proceed with adoption. If gaps surface, evaluate whether each is tolerable or a dealbreaker. You have 30 days on the trial; run 3 to 5 copies across different project types before committing.

Timeline: What to Expect

Total elapsed time: 1 to 5 business days from install to confident decision. If you use ScriptRunner for other purposes, audit your Script Registry before making the license call.

Common Questions

What if the Copy Project Plugin doesn’t copy custom field configurations? Custom field configurations in Jira are typically tied to field configuration schemes, which the plugin copies. During your parallel test, verify that custom field values appear correctly on copied issues. If specific configurations are missing, that’s exactly why you test before buying.

Can I keep ScriptRunner AND use the Copy Project Plugin? Yes. They run independently. Some admins keep ScriptRunner for listeners and behaviours while using the Copy Project Plugin for project duplication because it’s more reliable for that specific task.

The Copy Project Plugin has a small install base. Should I trust it? The 30-day free trial exists so you can judge by results, not install count. Copy a project, verify the output against the checklist above, and decide based on what you see in your environment with your data.

Data Center is being sunset in 2029. Is it worth switching plugins? Atlassian’s Data Center end-of-life is March 28, 2029, with existing customers able to expand licenses through March 2028. If you’re on DC today, you’ll be on it for years yet. A cheaper, more reliable project-copying tool pays for itself quickly.

What about Jira Server? Does this apply to me too? Yes. The Copy Project Plugin supports Jira Server 9.0.0 through 9.6.0. The parallel testing workflow is identical.

If ScriptRunner’s Copy Project is the only built-in script keeping your license active, a dedicated plugin that does one thing well at a fraction of the cost deserves a 30-day test. Install the Jira Copy Project Plugin trial from the Atlassian Marketplace, copy a project, and let the results speak for themselves. For questions or support, reach Lane Technology at support@lane.technology or visit the plugin documentation.

The “One Tool to Rule Them All” Pitch

A recent Atlassian Community article titled “Stop App Bloat: Power Up Jira with One Tool (And Pay for One)” makes the consolidation case directly: replace eight separate plugins ($8,910/year) with one Swiss Army knife tool ($2,000/year) and pocket $6,900 in savings. The math is appealing. Across the ecosystem, vendors are acquiring niche plugins and bundling them into suites. Community voices repeat the mantra: fewer apps, better Jira.

The logic holds up on the surface. Vendor management overhead is real. Procurement gets easier with fewer line items. Compatibility testing across eight plugins after a Jira upgrade is nobody’s idea of a good time.

But the consolidation argument confuses count with complexity. Going from eight apps to one changes nothing if that one app requires Groovy scripting, a 200-page documentation site, and a training course your team will never finish.

Plugin Bloat Is About Complexity, Not Count

Atlassian’s own community content on why Jira instances get slow points the finger at configuration bloat: thousands of unused custom fields, orphaned workflows, stale dashboards. The biggest performance killers are native configuration sprawl, and third-party apps sitting quietly in the background barely register.

There are two kinds of bloat, and the consolidation crowd is solving the wrong one.

Footprint bloat is resource consumption: memory, startup time, garbage collection overhead. Atlassian’s own documentation recommends monitoring plugin memory impact per plugin, rather than reducing total count. A lightweight, single-purpose plugin that activates when you use it has near-zero footprint. A scripting platform that’s always running and intercepting workflows has a permanent presence on your instance.

Cognitive bloat is what actually burns admin hours: learning curves, scripting requirements, debugging sessions when something fails silently. When admins inherit undocumented Groovy scripts written by predecessors who’ve moved on, those scripts become load-bearing infrastructure that nobody fully understands.

The real question is: how much complexity did each plugin add to my daily life?

A Concrete Example: Copying a Jira Project

You need to copy a Jira project (configuration, issues, attachments, the works). You do this a few times a month for new client engagements. Here are your options:

The scripting platform way: Write a Groovy script using the CopyProject API. Handle edge cases. Debug failures that produce no errors. One admin reported on the Atlassian Community that a scripted project copy created a project that was inaccessible; it appeared in API calls but getProjectObjByKey() returned null. It took 12 days to discover the fix was calling projectManager.refresh(), an undocumented step. Another admin reported that the same scripted approach copied the project structure but silently dropped every issue. No errors in the logs. The project was simply empty. Cost: thousands per year in platform licensing.

The single-purpose tool way: Install a dedicated project copy plugin like the Jira Copy Project Plugin, navigate to Projects → Copy Project, fill in three fields, click Copy. Workflows, roles, issues, attachments, subtasks: everything transfers in under a minute. Cost: a fraction of the above. Skills required: the ability to fill in a form.

For an operation you perform a few times a month, which is the right-sized tool?

The Unix Philosophy Has Guided Software for 50 Years

Doug McIlroy, inventor of Unix pipes, stated it in 1978: “Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.”

This principle has survived every shift in computing because it addresses a universal truth: complexity compounds, and the best defense is modularity. McIlroy himself later lamented that “adoring admirers have fed Linux goodies to a disheartening state of obesity,” the same force now at work in the Jira ecosystem, where plugins that started as focused tools accumulate features to justify enterprise pricing.

Before installing any plugin, ask: Does this tool do one thing well, or does it do many things adequately? Five lightweight tools that each solve one problem cleanly will always be easier to manage, debug, and replace than one monolithic platform woven into every workflow.

The Data Center Sunset Makes This Urgent

Atlassian has announced Data Center end-of-life on March 28, 2029, with new DC subscriptions ending March 2026. If you’re on Data Center today, you have roughly three years left.

Spending thousands per year on a sprawling scripting platform for infrastructure with a defined sunset is a different calculation than it was five years ago. A focused plugin at a few hundred dollars a year, one that pays for itself the first month and requires zero scripting expertise, is the rational investment for a narrowing window. This is about matching your investment to your time horizon.

The Jira community has confused “fewer plugins” with “simpler Jira.” Five focused tools that each solve one problem cleanly (without scripting, without training courses, without enterprise invoices) will always be simpler than one sprawling platform that does everything adequately and nothing simply.

Next time you evaluate a Jira plugin, skip “can this replace three other tools?” and ask instead: “does this do one thing well?” Your future self, and whoever inherits your instance, will thank you.

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

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.

Prerequisites

• Jira Data Center 10.0.0–10.7.4 (or Jira Server 9.0.0–9.6.0)
• Jira System Administrator permission (project admin is not sufficient)
• Network access to marketplace.atlassian.com from your Jira instance (see Troubleshooting for air-gapped installs)
• A source project to copy; use a dedicated template project with clean, current issues rather than a live project with stale data

Step 1: Install the Plugin

1. Log in to Jira as a system administrator.
2. Navigate to ⚙️ Administration → Manage Apps.
3. Click Find new apps in the left sidebar.
4. Search for “Jira Copy Project Plugin” by Lane Technology.
5. Click Install and confirm the prompt.
6. Click Free Trial to activate the 30-day Data Center trial. No credit card required.
7. Confirm the plugin appears under Manage Apps → User-installed apps with status Enabled.

On Jira 9.4.17+ and 9.12.4+, the Upload app link is disabled by default. This does not affect the search-and-install flow above.

Step 2: Copy Your First Project

1. Navigate to Projects → Copy Project in the top navigation bar.
2. Select the source project from the dropdown.
3. Enter the new project name (e.g., “ClientName - Onboarding Q2 2026”).
4. Enter the project key (e.g., “CNO26”). Keep keys short, uppercase, no spaces.
5. Click Copy.
6. The plugin redirects you to the new project when the copy completes.

The plugin copies workflows, roles, notification schemes, issues with attachments, components, versions, and subtasks in a single operation.

Post-Copy Verification Checklist

Run through this checklist after every copy:

• Workflow scheme: Open Project Settings → Workflows on both projects. Confirm they reference the same scheme.
• Project roles: Check Project Settings → People. Verify all roles have correct members and none are empty.
• Notification scheme: Confirm under Project Settings → Notifications that the scheme matches the source, not “Default Notification Scheme.”
• Issues: Open 3–5 issues. Verify status, assignee, and attachments transferred. Download one attachment to confirm integrity.
• Components: Check Project Settings → Components. Compare count and names to the source.
• Versions: Check Project Settings → Versions. Confirm all versions transferred with correct release dates.
• Subtasks: Open a parent issue. Confirm subtask relationships and statuses are intact.

What This Plugin Excludes

• Scrum/Kanban boards, saved filters, or dashboards
• Cross-project issue links
• Sprint data
• JSM-specific objects (queues, SLAs, request types)
• Copying across Jira instances
• Jira Cloud (Data Center and Server only)

Troubleshooting

Plugin not visible in “Find new apps”

Error: Search returns no results for “Copy Project.” Cause: Jira cannot reach marketplace.atlassian.com, which is common behind corporate proxies or in air-gapped environments. Fix: Add JVM proxy settings to setenv.sh or setenv.bat:

-Dhttps.proxyHost=proxy.yourcompany.com -Dhttps.proxyPort=8080

Restart Jira. For air-gapped instances, download the plugin JAR from the Atlassian Marketplace on a connected machine, then upload via Manage Apps → Upload app. On Jira 9.4.17+, add jira.plugin.upload.enabled=true to jira-config.properties first.

Copy operation times out on large projects

Error: Browser shows “504 Gateway Timeout” when copying a project with 1,000+ issues. Cause: Jira’s front-end enforces a 60-second request timeout (JRASERVER-67279). Fix: Increase the timeout in your reverse proxy. In nginx: proxy_read_timeout 300s;. Copy projects with 5,000+ issues during off-peak hours.

“Copy Project” missing from the Projects menu

Error: The Copy Project option does not appear after installation. Cause: Browser cache, insufficient permissions, or the plugin has not fully loaded. Fix: Hard-refresh (Ctrl+Shift+R). Confirm Jira System Administrator permission. Go to Manage Apps, disable then re-enable the plugin. On Data Center clusters, restart the node.

Notification scheme reverts to default

Error: New project shows “Default Notification Scheme” instead of the source’s custom scheme. Cause: Project-role-based notifications in the source scheme may fail to map correctly during copy. Fix: Reassign the correct scheme under Project Settings → Notifications. Verify the scheme exists at Administration → Notification Schemes.

Related Articles

• Jira Copy Project Plugin (Atlassian Marketplace): version compatibility, trial, and install
• Jira Copy Project Plugin (Documentation): feature details and support
• Installing Marketplace Apps (Atlassian Documentation): UPM reference guide
• Lane Technology Support: contact support@lane.technology for issues not covered here

This article is for admins staying on DC through at least 2028, whether by choice (regulated industries, data sovereignty) or by reality (migration complexity that won’t fit a 24-month window). These seven trends will shape your day-to-day work more than any migration whitepaper.

Trend 1: The March 2028 App Purchase Freeze Is the Real Deadline

By mid-2027, savvy DC admins will have completed full Marketplace app audits and locked in every license they’ll need through 2029. Those who wait until 2028 will find critical gaps they can never fill.

After March 30, 2028 at 23:59 PST, existing DC customers lose the ability to purchase new app subscriptions, expand user tiers, or buy new Marketplace apps. Only renewals of existing licenses are permitted. And new DC app submissions were permanently closed on December 16, 2025; the current catalog is all that will ever exist.

Every gap in your tooling (project cloning, bulk operations, advanced reporting, configuration backup) needs to be identified and filled before that date. Native Jira’s “Create with shared settings” still only copies configuration; issues, attachments, and subtasks are left behind. If your team needs full project duplication and you lack a tool for it by 2028, you never will.

Action: Build a DC App Audit checklist now. Map every admin workflow to its supporting tool. Trial and purchase by Q4 2027; procurement cycles eat months.

Trend 2: DC Plugin Vendors Are Shifting Resources to Cloud Before 2029

By the end of 2027, at least 30% of DC-compatible Marketplace apps will have shifted to maintenance-only or ceased DC updates entirely, even though official EOL is still a year away.

The resource shift is already visible. With no new DC app submissions allowed since December 2025, vendors have zero incentive to invest in DC-specific features. Development resources flow to Cloud where the growth is. Vendor release notes increasingly show Cloud-focused updates while DC versions receive only compatibility patches.

Appfire, the largest Marketplace vendor, announced 15–20% price increases on DC apps effective July 2025, while Cloud increases were only 5–10%. That pricing signal tells you where investment is heading.

The practical DC ecosystem is contracting faster than the official timeline suggests. An app you evaluate today may be in maintenance mode by 2028.

Action: When evaluating DC plugins, check the version history. If the last DC-specific update was 6+ months ago, that vendor is likely in wind-down mode. Prefer plugins with DC-compatible releases in the past 90 days.

Trend 3: The Feature Freeze Creates a “Standardization Imperative”

Organizations that codify project setup processes into reusable templates and tooling by late 2026 will maintain operational consistency through 2029. Those relying on tribal knowledge will face compounding configuration drift as admin turnover accelerates during a 3-year sunset.

As of March 30, 2026, DC products receive only security patches. No new features. The feature set you have today is the feature set you’ll have until 2029. That makes this the moment to lock in best practices while the admins who understand the correct configuration are still on staff.

Workflow management complexity and configuration inconsistency are already top admin pain points. During a 3-year sunset, when admins leave for roles on actively developed platforms, those problems compound.

Tools like the Jira Copy Project Plugin (under $500, 5-step UI) let admins duplicate a project’s full configuration and content (issues, attachments, subtasks, components, versions) so institutional knowledge lives in the template, not in someone’s head.

Action: Build a gold-standard template project. Install a cloning tool so any admin, including the one you haven’t hired yet, can replicate it in minutes.

Trend 4: The Cost-Per-Value Squeeze Is Getting Worse

DC customers will pay 30–50% more in total platform costs by 2028 compared to 2025, while receiving zero new capabilities. Low-cost efficiency tools become the highest-ROI investment category for remaining DC years.

Atlassian’s February 2026 DC price increase hit 15% for standard pricing and 18–40% for legacy Advantaged pricing. That followed a 2025 increase. With Appfire’s 15–20% DC app increases layered on top, cumulative costs are compounding for a platform receiving only security patches.

The ROI calculus shifts. Enterprise tools costing $1,200–$35,000/year become harder to justify on a maintenance-mode platform. Lightweight tools that solve specific problems (project cloning, bulk operations, configuration export) deliver outsized value at a fraction of the cost.

Action: Calculate your total DC cost trajectory through 2029: platform + app licenses + infrastructure. Identify expensive enterprise apps you’re underutilizing and evaluate whether focused, lower-cost alternatives cover your actual needs.

Trend 5: The Cloud Feature Gap Is Becoming a Morale Problem

By 2027, DC admins will face increasing internal pressure from users who see Cloud-only features and question why their instance feels stuck in 2025.

Jira Cloud now includes AI-powered automation, continuous UI updates, and native integrations that DC will never receive. The Atlassian Community discussion “Good-Bye Data Center” captures the growing frustration from admins caught between platforms. Community members have noted that many DC apps either lack Cloud equivalents or work differently after migration, creating barriers that keep organizations on DC even as the gap widens.

Users only see the capabilities they’re missing. Admins bear the brunt of that frustration.

Action: Create an internal stakeholder FAQ: “What our DC instance does and supports through 2029.” Pair it with a plan showing how you’re maximizing the platform’s remaining value. Proactive communication prevents reactive blame.

Trend 6: Regulated Industries Are Building “Fortress DC” Strategies

A significant minority of organizations, particularly in healthcare, finance, government, and defense, will still be running Jira DC instances past March 2029. The tooling decisions they make in 2026–2027 will determine whether those instances remain functional.

This is the trend most “migrate now” articles skip over. Atlassian’s own EOL page acknowledges “extended maintenance for certain Data Center customers by exception” after March 2029. Healthcare organizations face data sovereignty and compliance constraints that cloud migration fails to automatically resolve. Government and defense sectors refuse to accept data in external jurisdictions. Some organizations are even exploring reverse migration from Cloud back to DC due to compliance needs.

These organizations need to treat their DC instances as long-term infrastructure, which means investing in standardization and self-sufficiency tooling now, while the Marketplace is still open.

Action: If your organization might stay on DC past 2029, start the “extended maintenance” conversation with your Atlassian account executive now. Lock in all Marketplace licenses before March 2028. Build operational self-sufficiency.

Trend 7: The “Last-Chance” Plugin Audit Becomes a 2027 Priority

In 2027, “DC app audit” will become a standard IT project at organizations staying on Data Center. Those who treat it as a checkbox exercise will discover missing capabilities post-March 2028 that they can never fill.

Third-party automation dependencies are already flagged as a “ticking time bomb” in DC planning. Common audit gaps: project cloning (native Jira lacks issue copying), bulk operations, advanced reporting, and automation beyond basic workflows.

Categories to prioritize before March 2028:

• Project setup and templating: plugins that duplicate full project configurations and content
• Configuration backup and export: for eventual migration or archival
• Reporting and documentation: for compliance and knowledge preservation

Many tools in these categories offer 30-day free trials at low price points, making evaluation essentially risk-free.

Action: Start the audit in 2026. Build a spreadsheet mapping every admin workflow to its supporting tool, DC compatibility status, and vendor update recency. Trial everything before buying.

What This Means for Your 2026–2027 Planning

• Run your app audit now. The March 2028 cutoff is 24 months away. Trial periods, procurement approvals, and budget cycles mean evaluation must start in 2026.
• Standardize before your admins leave. Build template projects and install cloning tools while institutional knowledge still exists. A sub-$500 plugin pays for itself the first time it prevents a 3-hour manual setup.
• Calculate your true cost trajectory. Stack Atlassian’s 15%+ annual increases, vendor app increases, and infrastructure costs. Identify where focused, lower-cost tools can replace expensive enterprise suites you’re underutilizing.
• If you’re in a regulated industry, plan for post-2029. Atlassian has acknowledged extended maintenance “by exception.” Start that conversation now.

Methodology

These trends were identified through analysis of Atlassian’s official EOL timeline and pricing announcements, Atlassian Marketplace data (install counts, version histories, vendor activity), Atlassian Community forum discussions, vendor pricing updates, and industry analyst coverage of the DC sunset. Predictions are based on observable patterns (vendor behavior, pricing trajectories, marketplace freezes) extrapolated forward, and are specific enough to be validated by their stated timeframes. Analysis current as of March 2026.

This is a Jira architecture problem, not a discipline problem. Every project you manage is governed by seven or more independent scheme assignments, and native Jira gives you no reliable way to duplicate all of them (plus content) in a single operation. The result is configuration drift: projects that should be identical slowly and silently diverge, with consequences that compound across reporting, automation, and compliance.

The Real Cost of “Close Enough” Configuration

Configuration drift looks like a hygiene issue. In practice, it’s a systemic failure whose effects cascade and surface at the worst possible moments.

Broken automations. Automation rules that transition issues based on specific status names silently fail when a project uses a different workflow scheme. Atlassian’s own knowledge base documents that when workflows differ completely, “the transition buttons may disappear entirely”. When workflows are mostly but not entirely similar, “the issue may transition to a status other than the expected one.” The automation throws no error. It just stops working for that project.

Silent notification failures. If Project A uses Notification Scheme X and Project B accidentally uses Notification Scheme Y (which lacks the “Issue Assigned” event), assignees in Project B never get notified when work lands on their plate. You find out when someone misses a deadline and says, “I never saw it.”

Unreliable cross-project reporting. Dashboards and filters that aggregate across projects assume consistent issue types and statuses. When projects drift, your “All Open Bugs” filter silently excludes any project using “Defect” as its issue type name. Sprint velocity charts compare apples to oranges because two projects define “Done” at different workflow stages.

Compliance and audit exposure. In regulated industries (finance, healthcare, government contracting), every project must follow the same process. Consider a consulting firm with 30 active client projects that discovers during a quarterly review that 8 are missing the “Client Approval” workflow status their SLA reporting depends on. Three months of SLA data is unusable. The audit finding reads “your process fails to prevent mistakes,” not “your admin made a mistake.”

Why Drift Is Inevitable

Configuration drift happens to careful administrators because Jira’s architecture makes it nearly impossible to avoid through manual processes alone.

The Seven-Scheme Problem

Every classic Jira project is governed by at least seven separate scheme assignments: workflow scheme, permission scheme, notification scheme, issue type scheme, field configuration scheme, issue type screen scheme, and screen scheme, plus an optional issue security scheme. As the Atlassian Community’s configurations overview explains, a project takes these schemes and “involves all configurations.”

Setting up a new project means getting every one of those 7+ assignments right. Miss one, and that project silently deviates. There’s no native “compare project configurations” tool that flags the discrepancy. With seven or more independent scheme assignments, the ways a project can deviate from the template multiply with every project you create. Drift is a matter of when, not if.

The Shared-Scheme Trap

Jira’s “Create with shared settings” looks like the answer: new projects inherit the source project’s schemes. But it creates a coupling problem. As Dirk Ronsmans, an Atlassian Community Champion, confirmed: “If this is a shared configuration then that indeed means that the same configuration is used by multiple projects. So a change on the settings will be reflected in both projects.”

When one team’s lead asks you to add a workflow transition to “their” project, you’re actually adding it to every project sharing that scheme. You traded configuration drift for configuration coupling, which is arguably worse.

Admin Turnover and Click-Ops Culture

Most organizations maintain a Confluence page titled something like “How to Set Up a New Client Project.” The problem: it goes stale within weeks. The admin who wrote it leaves. The replacement follows the doc, but it references scheme names that were renamed six months ago.

Revyz describes this as “Click-Ops” culture: “There is no ‘commit message’ when you click a checkbox in the Jira UI. Consequently, the why of a configuration is lost the moment it is made.” The wiki page is now wrong, and no one knows it.

Native Jira Copies Config Shells, Not Complete Projects

Even when you get the configuration right, Jira’s built-in project creation copies settings only, excluding issues, components, versions, and subtasks. Atlassian’s own documentation directs users to third-party Marketplace apps for full project copying.

For teams that use template projects with pre-loaded issues (a “Client Onboarding” project with 25 standard tasks, a “Sprint Zero” project with setup checklists), this means manually recreating that content every time. Content drift compounds configuration drift.

Why the Common Fixes Fall Short

You’ve probably already tried (or at least evaluated) the usual approaches. Each one solves part of the problem while creating new ones.

Wiki-based setup checklists require perfect discipline and must never go stale. Neither condition holds in practice. The Atlassian Community’s survey of top admin challenges lists managing large-scale workflow customizations and automating repetitive admin tasks among the most persistent daily frustrations. A checklist merely documents the complexity, badly, once.

Shared configuration schemes create coupling, not consistency. The workaround (copying a scheme to break the link so you can modify it independently) puts you right back at square one: manually configuring a new project’s schemes.

ScriptRunner automation is powerful but demands Groovy scripting expertise. The Atlassian Community’s tutorial on automated project creation describes building “a switch-case structure to map each template type to its respective set of schemes”; custom code that someone must write, test, debug, and maintain. At $5,000+/year for Data Center licensing, that’s expensive for a single use case.

Enterprise configuration management tools designed for cross-environment migration (promoting configurations from staging to production) start at $1,200/year and scale to $35,000+. If all you need is to copy a project faithfully, that’s a truck when you need a bicycle.

The Configuration Drift Audit

Before you fix the process, find out how bad the damage is. This audit framework works regardless of which tool you use going forward.

1. Pick your gold-standard project. Identify the one project you’d want every new project to match: the one with the correct workflows, roles, and notification schemes.

2. Export its scheme assignments. Document the gold standard’s workflow scheme, permission scheme, notification scheme, issue type scheme, field configuration scheme, issue type screen scheme, and screen scheme. Navigate to Project Settings for each scheme type, or use the REST API endpoint /rest/api/2/project/{projectKey} to pull scheme associations programmatically.

3. Compare against every project that should match. For each project, check all seven scheme assignments against the gold standard. Flag any deviation; even a single mismatched scheme means that project behaves differently.

4. Check content consistency. Compare components, versions, and available issue types across projects. Are the same components present? Same version names?

5. Test automations across projects. Run your global automation rules and confirm they fire correctly in every project. Projects with different workflow statuses or missing issue types will silently fail.

6. Document the delta. Build a simple matrix: projects as rows, scheme types as columns, green for match, red for mismatch. This gives you a visual map of exactly where drift has occurred.

If more than three projects show deviations, the process is the problem, not individual mistakes. The matrix you just built is the evidence that a structural fix is needed.

Template Projects Plus Full-Fidelity Copying

The pattern that eliminates drift is straightforward: maintain one gold-standard template project with the correct workflows, roles, notification schemes, and pre-loaded issues, components, and versions. For every new project, duplicate the template completely (configuration and content) in a single operation.

This addresses every root cause simultaneously. The seven-scheme manual assignment problem disappears because all schemes are copied automatically. The shared-scheme coupling problem is gone; each new project gets its own independent scheme copies instead of shared references. The content gap is closed: issues, components, and versions come pre-loaded. And the approach survives admin turnover, because the template is the documentation.

How the Jira Copy Project Plugin Implements This

The Jira Copy Project Plugin by Lane Technology was built specifically for this pattern. It copies both configuration (workflows, roles, notification schemes) and content (issues with attachments, components, versions, subtasks) in a single five-step operation accessible from Projects → Copy Project. Select your source template, name the new project, click copy, and you’re redirected to a fully populated duplicate.

It requires no scripting, API calls, or external dependencies. The plugin operates entirely within your Jira instance; no data leaves your environment, which matters for regulated industries and privacy-conscious organizations. It supports Jira Server 9.0–9.6 and Data Center 10.0–10.7.4, with a 30-day free trial on Data Center so you can validate it in your environment before committing.

For context: native Jira copies configuration only, excluding issues and content. ScriptRunner requires Groovy and costs $5,000+/year. Enterprise migration tools start at $1,200/year. The Copy Project Plugin does one thing (full-fidelity project duplication) simply and affordably.

Preventing Future Drift

Fixing drift once is half the job. Keeping it fixed requires three process changes:

• Lock down your template project. Use permission schemes to restrict edits to designated Jira administrators only. The template is your single source of truth; treat it accordingly.
• Schedule quarterly audits. Use the audit framework above to catch projects modified after creation. Drift is silent; you have to look for it.
• Update the template deliberately. When workflows or schemes need to evolve, update the template first, validate the changes, then apply them to existing projects. Modifying a live project and hoping to backport the change later always fails.

Configuration drift is what happens when humans manually replicate seven or more independent scheme assignments across dozens of projects with no verification step. The fix is removing the manual process entirely: a verified template project, duplicated completely for every new project, so consistency is built into creation rather than bolted on afterward.

Start a free 30-day trial of the Jira Copy Project Plugin and see the template-plus-copy approach working in your own environment.

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

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):

1. Create new project with shared configuration (5 min)
2. Export 25 issues to CSV from the template project (10 min)
3. Import CSV into new project, troubleshoot field mapping errors (20 min)
4. Discover attachments didn’t transfer; manually download and re-upload 60+ files (45 min)
5. Recreate 6 components manually (10 min)
6. Recreate 4 versions manually (5 min)
7. Verify subtask relationships, find they’re broken, manually re-link (30 min)
8. 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.

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.

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.

How Shared Configuration Works

When you select “Create with shared configuration,” Jira creates a new project and points it at the exact same scheme objects used by the source project. The new project gets references to those schemes, not copies of them.

The consequence catches most admins off guard. As Atlassian Community Champion Trudy Claspill confirmed: “If at a later date you make a change to any of those Schemes, those changes affect all projects that use the changed Scheme.” Edit a workflow in one project, and every project sharing that scheme changes too. To make a project independent afterward, you must manually copy each scheme and reassign, negating most of the time savings.

What shared configuration excludes entirely:

• Issues, attachments, and subtasks
• Components and versions
• Boards (Scrum/Kanban) and sprint data
• Project role member assignments (individual users; groups in roles are shared)
• Issue security scheme, project category, default assignee, and custom field contexts

These exclusions are by design. Components and role assignments are “not schemable”; they have never been part of Jira’s scheme system. A separate feature request (JRASERVER-60335, 41 votes) asks Atlassian to add role copying, also still unresolved.

Shared Configuration vs. Full Project Cloning

Shared configuration gives you an empty shell wired to shared schemes. Full project cloning gives you a standalone replica: configuration and content together.

Quick Examples

• Good fit: A DevOps team where every project follows the same ITIL workflow and process changes should roll out everywhere simultaneously.
• Poor fit: An agency creating client projects from a template. They need issues, components, and versions copied, plus the freedom to customize workflows per client without affecting other projects.
• The surprise scenario: An admin edits a notification scheme for one project, unaware that 12 other projects share it. All 12 now send unexpected notifications.

If shared configuration’s limitations are blocking your workflow (especially the missing ability to copy issues and content) a project cloning plugin can duplicate both configuration and content in a single operation, with independent scheme copies so changes stay isolated.

Why Ad-Hoc Project Creation Fails at Scale

Most admins maintain a Confluence page documenting “how to set up a new client project.” It’s always outdated. Atlassian’s own governance guidance acknowledges the need: “Writing down rules and guidelines, or governance documents, ensures admins are on the same page with configuration and change control.” But static documentation lacks enforcement, and it falls behind workflow scheme changes that happen between reviews.

Meanwhile, native Jira’s “Create with shared settings” copies schemes (workflow, notification, permission) but delivers an empty shell. No issues, no attachments, no subtasks, no components, no versions. That’s half the job done, at best.

The result is what Revyz calls “the silent decay”: configuration drift where “your production environment becomes a unique, unrepeatable instance that exists nowhere else, not in your Sandbox, and certainly not in your documentation.” They categorize three drift types: operational drift (ad-hoc workflow changes), security drift (permission scheme erosion), and infrastructure drift (accumulation of unused assets). Each starts with a single project set up slightly differently than the last.

The math: at 1–4 hours per project × 12 projects per quarter = 12–48 admin hours per quarter on repetitive setup. Up to six working days, and the output still lacks consistency.

The TCV Framework Explained

TCV replaces the ad-hoc checklist with a three-phase lifecycle. Each phase has a specific purpose, and the critical innovation is the feedback loop connecting the end back to the beginning.

┌──────────────┐      ┌──────────────┐      ┌──────────────┐
│   TEMPLATE   │ ───► │     COPY     │ ───► │   VALIDATE   │
│              │      │              │      │              │
│ • Design     │      │ • Full-      │      │ • 12-point   │
│   gold-      │      │   fidelity   │      │   post-copy  │
│   standard   │      │   duplication│      │   audit      │
│   source     │      │   of config  │      │ • Confirm    │
│ • Lock down  │      │   AND content│      │   schemes,   │
│   config     │      │ • Atomic     │      │   issues,    │
│ • Pre-load   │      │   operation  │      │   attachments│
│   content    │      │ • 5–15 min   │      │ • 15–30 min  │
│              │      │              │      │              │
│ Setup: 2–4hr │      │              │      │              │
│ Maint: 30min/│      │              │      │              │
│ quarter      │      │              │      │              │
└──────────────┘      └──────────────┘      └──────┬───────┘
       ▲                                           │
       │         Validation failures trigger        │
       └───────── template updates ◄───────────────┘

Template is the gold-standard source project: locked-down configuration AND pre-loaded content (issues, components, versions). It serves as the single source of truth, separate from any living project that accumulates ad-hoc changes.

Copy is full-fidelity duplication (config AND content) using tooling rather than manual recreation. The copy must be atomic: everything transfers in one operation. Partial copies reintroduce the drift TCV exists to eliminate.

Validate is a structured post-copy audit confirming that what was supposed to transfer actually did, before the project goes live.

The framework’s real value is in the feedback loop. Most admins who use template projects skip validation; they copy and move on. When something breaks two weeks later, they fix it in the live project but never update the template. Every future copy inherits the original flaw. TCV closes this loop: validation failures trigger template updates, so the source improves over time instead of decaying.

How to Apply the TCV Framework

Phase 1: Template

1. Create a dedicated template project with a clear naming convention. The Atlassian Community recommends including “Template” in the project name so it stands out. Something like TPL-ClientEngagement signals immediately that this project is a source, not a workspace.

2. Configure all schemes deliberately. Assign the exact workflow scheme, notification scheme, permission scheme, and issue type scheme this project type requires. Set each one explicitly rather than inheriting defaults. Isos Technology’s governance best practices recommend that shared projects “use consistent nomenclature for statuses” and standardize schemes for better visibility.

3. Pre-load content. Create the standard issues, subtasks, components, and versions every new project of this type should start with. An agency’s client onboarding template might include epics for Discovery, Setup, Execution, and Review, each with 3–5 standard subtasks.

4. Lock it down. Restrict edit permissions to Jira admins only. Add a project description: “THIS IS A TEMPLATE. DO NOT MODIFY WITHOUT GOVERNANCE APPROVAL.” This is the difference between a stable source and yet another project that drifts.

5. Schedule quarterly audits. Review the template against current organizational standards. When workflows or schemes change at the org level, the template must be updated; otherwise every future copy will be born outdated.

Phase 2: Copy

Copying configuration alone creates an empty shell. Copying issues alone misses scheme assignments. The Copy phase must transfer both config and content in one atomic operation.

For teams that need one thing (copy a project completely) a purpose-built tool like the Jira Copy Project Plugin is the right-sized solution. Five clicks, no scripting, no data leaving the instance. ScriptRunner requires Groovy expertise and costs an order of magnitude more. Project Configurator is designed for cross-environment migration; it’s powerful, but overkill for single-instance duplication.

After copying, immediately update the project name and key to match your naming convention.

Phase 3: Validate

Run this checklist before declaring any new project live.

Close the feedback loop. If any check fails, fix the new project and then investigate whether the template needs updating. If the template’s notification scheme was wrong, every future copy inherits the same error. Fix the source, not the symptom. This feedback loop is what makes TCV self-correcting rather than a static checklist.

TCV in Practice: A Consulting Firm’s Before and After

Consider a 150-person management consulting firm running Jira Data Center 10.x. They provision 12 client engagement projects per quarter, each following the same structure: identical workflows (Discovery → Active → Review → Closed), standard roles (Engagement Lead, Consultant, Client Stakeholder), a notification scheme routing updates to the engagement lead, and 18 template issues under 4 epics.

Before TCV: Each new project took approximately 3 hours; 45 minutes configuring schemes, 2+ hours recreating issues manually. The team logged 2–3 configuration errors per month, caught by PMs weeks after go-live. The most common: a missing notification scheme that meant engagement leads stopped getting issue updates. Total quarterly admin time on project setup: ~36 hours.

After TCV: A 4-hour one-time investment created the template project with all schemes, roles, and 18 standard issues. Using the Jira Copy Project Plugin, each new project takes ~5 minutes. The 12-point validation checklist adds ~10 minutes. In the first quarter, validation caught a missing component in the template itself; the feedback loop triggered a template update that fixed it for every future project.

Result: 15 minutes per project versus 3 hours. Across 12 quarterly projects: 33 hours saved per quarter. Zero configuration drift incidents since adoption. The old Confluence checklist was retired and replaced by the validation checklist, a living artifact that evolves with the template instead of decaying beside it.

When to Skip This Framework

TCV has clear limits. Skip it if:

• You create fewer than 1–2 projects per quarter. The overhead of maintaining a template and validation checklist outweighs the benefit at low volume.
• Every project is structurally unique. TCV assumes repeatability. If no two projects share the same workflows or role structures, a template adds nothing.
• You already run enterprise configuration management tooling. If Project Configurator handles your environment promotion or ScriptRunner automates provisioning via CI/CD, TCV is a simpler approach than what you already have.
• You’re actively migrating to Jira Cloud. Investing in a Data Center-specific provisioning process during migration is counterproductive. Atlassian has announced Data Center end-of-life for March 2029; TCV is for teams committed to on-premises through that window.
• You need cross-instance copying. TCV operates within a single Jira instance. Promoting configurations from staging to production requires different tools.

TCV turns project provisioning from a repetitive manual task into a governed lifecycle that improves itself over time. The Template and Validate phases are pure process; they cost nothing to adopt. The Copy phase is where tooling choices matter. For teams that need complete project duplication without enterprise complexity, the Jira Copy Project Plugin offers a 30-day free trial to operationalize it. Print the 12-point validation checklist, tape it to your monitor, and never forget a notification scheme again.