How to find all duplicated Issue Type Schemes in Jira?

[Rumceisz]

Hi,

I just became a site-admin of a Jira. The instance administration was a complete mess: each time when a project was created, the former admins created a separate Issue Type Scheme.

Right now there are hundreds of Issue Type Schemes and plenty of them are similar but with different names of course.

For example: There are 6 Issue Type Schemes with exactly these Issue Types:

Story, Bug, Task, Sub-Task, CR

My question is: how can I find the exact similar Issue Type Schemes and delete the duplications? With that I could reduce the number of Issue Type Schemes by hundreds.

Thank you!

[Gor Greyan]

Hi @Rumceisz

Welcome to the Atlassian Community!

For Jira Data Center, Jira doesn't provide a built-in “find duplicate Issue Type Schemes” function. Jira DC exposes the Issue Type Scheme REST API, and you can retrieve the schemes together with their issue types using

GET /rest/api/2/issuetypescheme?expand=schemes.issueTypes

You can then compare the issue type IDs assigned to each scheme, sort those IDs, and group schemes that have the same set. This will quickly identify cases where, for example, six differently named schemes all contain the same Story, Bug, Task, Sub-task, and CR issue types. 

Another solution can be via ScriptRunner, I think. If you have it, let me know; I will try to create a script that will retrieve that duplication.

Regards
Gor

[Rumceisz]

Hi Gor,

I have Scriptrunner! Few scripts could make so far but this is a big accomplishment would be for me now.

Thank you!

[Nicketa]

Hi @Rumceisz,

Cleaning up inherited Jira instances with hundreds of duplicate schemes is a very common challenge!

Try the below methods for the existing. For new set-up 
It's best to have a common project as a default template and for any new project just share the settings. If anyone needs a specific settings, then they can raise a request and you guys can seperate it.

1. The REST API 
Try to run a lightweight Python script using the Jira Cloud REST API (`/rest/api/3/issuetypescheme` and `/rest/api/3/issuetypescheme/mapping`). The script fetches all schemes, sorts their issue type IDs, and groups identical schemes together into a clean report.

Run this script locally:

from collections import defaultdict
import requests
from requests.auth import HTTPBasicAuth

# --- CONFIGURATION ---
JIRA_URL = "https://your-domain.atlassian.net"
EMAIL = "your-email@domain.com"
API_TOKEN = "your-api-token"

auth = HTTPBasicAuth(EMAIL, API_TOKEN)
headers = {"Accept": "application/json"}

print("Fetching all Issue Type Schemes...")

# 1. Fetch all Issue Type Schemes (Paginated)
schemes = []
start_at = 0
max_results = 50

while True:
url = f"{JIRA_URL}/rest/api/3/issuetypescheme?startAt={start_at}&maxResults={max_results}"
res = requests.get(url, auth=auth, headers=headers).json()
values = res.get("values", [])
schemes.extend(values)

if res.get("isLast", True) or not values:
break
start_at += len(values)

print(f"Total schemes found: {len(schemes)}")

# 2. Map schemes to their issue types
scheme_map = defaultdict(list)

for scheme in schemes:
scheme_id = scheme.get("id")
scheme_name = scheme.get("name")

# Fetch mapping for each scheme
map_url = f"{JIRA_URL}/rest/api/3/issuetypescheme/mapping?issueTypeSchemeId={scheme_id}"
map_res = requests.get(map_url, auth=auth, headers=headers).json()
mappings = map_res.get("values", [])

# Sort Issue Type IDs to create a unique fingerprint
issue_type_ids = tuple(
sorted([m["issueTypeId"] for m in mappings if "issueTypeId" in m])
)

scheme_map[issue_type_ids].append(
{"id": scheme_id, "name": scheme_name, "is_default": scheme.get("isDefault", False)}
)

# 3. Print Duplicate Report
print("\n" + "=" * 60)
print(" DUPLICATE ISSUE TYPE SCHEMES REPORT")
print("=" * 60 + "\n")

duplicate_count = 0
for issue_types, scheme_list in scheme_map.items():
if len(scheme_list) > 1:
duplicate_count += 1
print(
f"Group #{duplicate_count} — Shares Issue Type IDs: {issue_types}"
)
for s in scheme_list:
default_flag = " (DEFAULT SCHEME)" if s["is_default"] else ""
print(f" • ID: {s['id']:<6} | Name: {s['name']}{default_flag}")
print("-" * 60)

if duplicate_count == 0:
print("No duplicate issue type schemes found!")

2. Quick UI Audit (Unused Schemes)
Go to Jira Settings > Issues > Issue type schemes and check the >Projects>column. Any scheme with 0 Projects can be safely deleted right away.

[Mohammad Mahyar ahmadi]

Hi @Nicketa, thanks for adding a script here — just flagging one thing for anyone who copies it: /rest/api/3/issuetypescheme and /rest/api/3/issuetypescheme/mapping are the Jira Cloud REST API. This question is tagged Server/Data Center, and Jira DC only exposes /rest/api/2/... (there's no Cloud-style v3 on DC), so this script would 404 as written on a Server/DC instance.

The read/group approach itself is solid though — it works the same on DC once the endpoint is swapped to v2. I posted a DC-specific version of the read + safe-delete flow in my answer below (tested on Jira DC 11.3.7), including why the Cloud-style project-reassignment endpoint doesn't exist on DC either.

[Rumceisz]

Thank you for your hints but I'm on Jira Data Center. Is that script working there too?

[Nicketa]

Thanks @Mohammad Mahyar ahmadi , Thanks for pointing that out. You're absolutely correct, I overlooked the fact that the question is tagged for Jira Data Center / Server and my example was written using the Cloud v3 REST APIs. I missed the tag. by seeing site-admin I assumed as cloud. 

[Nicketa]

Hello @Rumceisz 

Since you're on Jira Data Center and already have ScriptRunner, you can identify duplicate Issue Type Schemes directly within Jira without needing external tools.

The idea is to create a unique "fingerprint" for each scheme based on its Issue Types, then group schemes that have the exact same set of Issue Types. Similar to what Gor Greyan suggested via the REST API approach, but executed directly inside Jira using ScriptRunner. 

A few recommendations before deleting anything:

• Check whether the schemes have the same default Issue Type. Two schemes can contain the same Issue Types but still behave differently if their defaults differ.
• Review project associations first. If multiple projects are still using a duplicate scheme, re-associate them to the scheme you plan to keep.
• Any scheme with no associated projects can typically be considered for deletion after validation.

My preferred cleanup process for large legacy instances is:

• Identify duplicate groups.
• Choose a "master" scheme for each group.
• Reassociate projects from duplicate schemes to the master.
• Delete unused schemes.
• Re-run the report to confirm the cleanup.

[Mohammad Mahyar ahmadi]

Hi Rumceisz,

Adding to Gor's answer - his grouping method is the right way to find them. I want to cover the second half of your question, deleting them, because there's a hard limit here that isn't obvious until you hit it.

First, to see which projects are actually using a scheme before you touch it:

GET /rest/api/2/issuetypescheme/{schemeId}/associations

That returns the full project objects attached to that scheme - not just IDs, the whole project resource, key, name, lead, roles and all. If it comes back empty, the scheme is safe to delete outright:

DELETE /rest/api/2/issuetypescheme/{schemeId}

I checked this on my own instance (Jira DC 11.3.7) before answering rather than trusting the docs: created a throwaway scheme, confirmed associations came back empty, deleted it - 204 No Content, clean.

Here's the part that will actually block you. If a scheme still has a project on it, the plan is presumably to move that project to the surviving scheme, then delete. On Jira Cloud there's a PUT /rest/api/3/issuetypescheme/project endpoint that does exactly that reassignment. On Server/Data Center that endpoint doesn't exist - I tried the equivalent, PUT /rest/api/2/issuetypescheme/project, and it came back 400, because Jira read "project" as a literal scheme ID and tried to parse the body as a scheme update instead of an assignment. It's not a version quirk on my end either - there's an open feature request for it, JRASERVER-59948, and reassigning a project's issue type scheme on Server/DC is UI-only (Project settings - Issue Types - Actions - Associate Scheme) unless you script it with something like ScriptRunner's IssueTypeSchemeManager.

So with hundreds of schemes, the realistic workflow is: group by issue type set with Gor's method, pull associations for every candidate, reassign the projects still sitting on a duplicate scheme through the UI or a script, and only then hit those schemes with DELETE from the API. The API gets you the read and the cleanup, not the reassignment in the middle.

One more thing worth checking before you collapse any group: the issueTypes list from the grouping call doesn't include a scheme's default issue type - I only saw that field on a scheme's full resource, not in the expand=schemes.issueTypes list. Two schemes with the identical issue type set can still have different defaults, and that difference won't show up in the comparison Gor's method uses. Worth a second look before you delete something a project depends on for its default type.

Hope that helps.

[Deniz Oğuz - The Starware]

Hi,

Connect an ai to jira using either rest api or mcp and ask it to give you the name of issue type schemas with exact issue type configurations. 

[Nicketa]

mcp costs license.