How to Switch from ScriptRunner's Copy Project to the Jira Copy Project Plugin on Data Center

You inherited a ScriptRunner Data Center license (or maybe you bought it yourself) and the main thing you use it for is the built-in Copy Project script. You don’t write Groovy. You don’t use listeners, behaviours, or custom REST endpoints. You navigate to Admin → Built-in Scripts → Copy Project, check some boxes, and copy a project.

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.

ScriptRunner Copy Project Option Jira Copy Project Plugin Notes
Workflow schemes (always copied) ✅ Copied 1:1 equivalent
Notification schemes (always copied) ✅ Copied 1:1 equivalent
Role memberships (always copied) ✅ Copied 1:1 equivalent
☐ Copy versions ✅ Always copied Versions are always included; no opt-out
☐ Copy components ✅ Always copied Components are always included; no opt-out
☐ Copy issues and attachments ✅ Always copied (including subtasks) Issues, attachments, subtasks always included
☐ Copy Agile boards ❌ Not copied Create board manually after copy
☐ Copy filters and dashboards ❌ Not copied Recreate or share filters manually
☐ Copy request types (JSM) ❌ Not supported Plugin handles Jira Software only
☐ Copy queues / SLAs (JSM) ❌ Not supported Plugin handles Jira Software only
REST API / programmatic trigger ❌ UI-only No API, no automation hooks
Selective element copying ❌ All-or-nothing Cannot exclude specific elements
Custom field configurations ⚠️ Verify in testing Typically inherited via shared schemes

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:

Verification Check ScriptRunner Copy Plugin Copy Match?
Project accessible in UI immediately?      
Correct workflow scheme assigned?      
All project roles populated correctly?      
Notification scheme matches source?      
Issue count matches source?      
Subtask count matches source?      
Attachments present on issues?      
Components match source?      
Versions match source?      
Custom field values preserved?      

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

Phase Duration What happens
Install + first test copy 1 hour Install plugin, copy one project, verify output
Parallel testing (3 to 5 projects) 1 to 3 days Copy representative projects with both tools, compare using checklist
Decision Same day testing completes Review comparison results against feature-mapping table
Adoption Immediate Start using the plugin for new project copies
ScriptRunner license decision At next renewal Let ScriptRunner lapse if no other features are in use

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.