Recommended approach to replacing issue types

[shane-nz]

My business owner wants to globally replace an existing issuetype with another

The issuetype in question was a singular RAID item that captured all 4 risk objects (Risk, Assumption, Issue and Dependency) in conjunction with a custom field.
The request is to now have 4 independent issuetype mapping to each risk element.

One of the requirements is for staff to no longer be able to Create the old RAID issuetype.
Another requirement is to have old information still searchable/findable
 
I initially thought to migrate/move the existing issues to the new issuetypes then remove the old RAID issuetype

Have contemplated scripting this with Scriptrunner for Jira with removing RAID as an option from the create dialog, whilst keeping the old RAID issues for records keeping. I am not 100% confident this will disable create across all apps and features within Jira. 

Which of the two would be most recommended or is there any other way.

  

[Carla Ann Rowland]

As a data center Administrator I have had similar requests and usually I would do a full replacement as you initially thought.

Since your leadership wants to keep the the original RAID issue type and migrate to the NEW issue type then the best option is to keep the both issue types. Take the Old issue type and put a create security role on it so only people in a specific role can created a new ticket. you would have to ensure that the old ticket type once it is closed is visible to all. Once these settings are in place then I think you will be good to go.

[Trudy Claspill]

Hello @shane-nz 

Have you considered starting a new project with the new issue types? Then change the permissions on the original project to remove allocation of the permissions that enable creating and updating issues, effectively making it read only. The historic data would be searchable. New issues of the old type would not be creatable if you don't include that issue type in the new project.

[shane-nz]

The intent is to introduce the new issue types across all existing projects. 

Unless I am mistaken the above suggestion may not scale across my org, we have roughly 500+ Active projects. (apologies I missed that info)

[Trudy Claspill]

Thank you for that additional information. My suggestion would definitely not scale to support that requirement.

Do these projects share a common workflow for the current RAID issue type? Do they share a common screen for the Create operation for the RAID issue type?

I know that Scriptrunner Behaviours could be used to remove the issue type from the Create Issue dialog, but that would not prevent it from being accessed in the Move Issue function and would not block those types of issues from being created via API calls. I don't know if there are other scripting options available that could be used to block those other paths.

If the RAID issue type shares a workflow across the projects, then you could potentially add a validator to the Create transition that will always evaluate as false to prevent the issue from being created. That again won't be effective if using the Move Issue option to move an issue from another issue type to the RAID issue type.

I asked Chrome Gemini:

In Jira Data Center what is the best practice for deprecating a current issue type while keeping the data available for searching?

And this is the response it gave:

The best practice for deprecating an issue type in Jira Data Center while keeping data searchable is to rename the issue type (e.g., "Old - Bug"), remove it from Issue Type Schemes, and use Workflow properties to prevent editing, while allowing it to exist on historical issues. This keeps existing data searchable and intact, while stopping new creations.

Steps to Deprecate and Preserve Data:

• Rename the Issue Type: Rename the current issue type to include "(Deprecated)" or "Old" to notify users.
• Remove from Scheme: Remove the deprecated issue type from all active Issue Type Schemes in project settings. This stops new issues of this type from being created in that project.
• Update Workflows: Apply a workflow property to the deprecated type: jira.issue.editable = false to prevent changes to old data.
• Handle Existing Issues: Do not use "Bulk Move" to change the type, as this changes historical data. The old issue type will remain attached to those issues and still be searchable via JQL (issuetype = "Old - Bug").
• Optional - Restrict Access: Change the Issue Type's color to grey, or update field configurations to make fields on it read-only. 

This approach avoids losing data and allows users to search for historic issues while stopping new creation.

Disclaimer: I don't have a Data Center environment when I can actually test this recommendation, so use it at your own risk.