Finding and safely deleting duplicate Issue Type Schemes in Jira Data Center

[#1]

If you've inherited a Jira Data Center instance where every new project got its own Issue Type Scheme, you already know the number climbs into the hundreds fast. Most of them hold the exact same issue types under a different name, because whoever set the project up didn't know an identical scheme already existed.

Jira Data Center has no built-in "find duplicates" button for this. The REST API gets you there, but the delete half has a catch that isn't documented anywhere obvious.

Finding the duplicates

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

This returns every scheme on the instance along with its issue type list. Sort each scheme's issue type IDs and group the schemes that come out identical - that's your duplicate set. On an instance with a few hundred schemes this usually surfaces a handful of groups of two or three schemes that are genuinely interchangeable, plus a lot of near-misses that only look the same until you check the details.

Checking what's using each scheme

Before deleting anything, you need to know which projects are actually on a scheme:

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

I didn't expect much from this one, but it returns the full project resource for every project on that scheme - key, name, lead, roles, the works, not just an ID you'd have to look up separately. An empty array means nothing is using the scheme and it's safe to remove outright.

The part that will actually block you

Once you've grouped duplicates and found a scheme still attached to a project, the obvious next step is: move the project to the scheme you're keeping, then delete the empty one. On Jira Cloud there's a dedicated endpoint for exactly that:

PUT /rest/api/3/issuetypescheme/project

Data Center doesn't have it. I tried the equivalent path, PUT /rest/api/2/issuetypescheme/project, on my own instance (Jira DC 11.3.7) and got a 400 - Jira parsed "project" as a literal scheme ID and tried to read the request body as a scheme update instead of an assignment. This isn't a version-specific bug either; there's a long-standing open feature request for it (JRASERVER-59948), and reassigning a project's issue type scheme on Server/Data Center is UI-only - Project settings, Issue Types, Actions, Associate Scheme - unless you script it with something like ScriptRunner's IssueTypeSchemeManager.

So the cleanup can't be a single script end to end. The read and the delete are API calls; the reassignment in the middle is a manual step, or a scripted one outside the REST API.

Deleting what's left

Once a scheme has no projects on it:

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

I tested this on a throwaway scheme with zero associations and got 204 No Content back - clean, no leftover reference anywhere I could find.

One gotcha in the grouping step itself

The expand=schemes.issueTypes call that does the grouping doesn't surface a scheme's default issue type. I only saw that field when I fetched a single scheme's full resource, not in the list response used for comparison. Two schemes can carry the exact same set of issue types and still disagree on which one is the default - sorting the IDs won't catch that. If you collapse two schemes that differ only in their default, the project that inherits the "wrong" one will start creating a different issue type than it used to whenever someone picks the default. Worth checking before you merge a group, not after.

Putting it together

For a handful of schemes this is fast enough to do by hand. For hundreds, the realistic workflow is: pull every scheme with its issue types, group by identical sets, pull associations for every scheme in a group, reassign the projects still sitting on a duplicate through the admin UI or a script, check the defaults match before you do, and only then delete the emptied schemes through the API. Run the whole pass read-only first and decide the survivors on paper - the delete step is the one part of this you can't undo from the API.

Worth knowing

Reading scheme data needs browse permissions on the relevant projects; deleting a scheme needs Jira administrator rights. If associations comes back empty for a scheme you're sure is in use, check permissions before you trust the empty result.

I tested all of this on Jira DC 11.3.7. The endpoints involved are old and stable, so I'd expect the same behavior on other current DC versions, but if you're on something considerably older, the safe move is the same one I did - create a throwaway scheme, check associations, delete it, and confirm before you run this against real data.

If you've found a better way to do the reassignment step - scripted, plugin-based, anything that beats clicking through the UI project by project - I'd be curious to hear it.

Disclosure: I am an IT and Jira administrator, and I do independent Jira and Confluence consulting on the side. I write up Jira Data Center notes like this one at jirasupport.ir - that site is in Persian.