How to change custom field types in Jira
Summary
The purpose of this article is to show how you can change the type of an existing Custom Field. An existing request for this to be possible within JIRA has been closed as Won't Fix - JRA-19312Getting issue details... STATUS
Migrating Custom Field content to another field using CSV import
Please note this workaround is only applicable if all issues are all in the same project. You can apply this several times for different projects or change it to include project name/key/type to import the project as well.
- Create the new Custom Field
- Do a JQL search for all issues that are using the other custom field
- Export as Excel file with those issues containing only these two columns:
- The issue key
- The value in the custom field
- Open in an Excel editor
- Remove the first 3 lines and the last line after the data (so there’s only the header and the data)
- Add a ‘Summary’ column with no data in any issue (make sure not to add anything to this column other than name in the header, otherwise the summaries will be replaced for all issues it has a value)
- Edit the data to be added in the Custom Field, if needed (for example, if you're moving from a multi-line to a single-line text field, you may need to remove new lines, if it's from text to numeric, make sure there are only numbers, etc.)
- Save as CSV
- Import the CSV, mapping:
- The Summary to Summary (since it’s empty, it won’t do anything, but it’s required)
- The issue key to the issue key (so JIRA knows what issues to change)
- The value to the new custom field (changing the custom field)
Migrating Custom Field content to another field using bulk operation
This approach is done with the use of bulk edit operations to migrate content manually from one field to another:
Please note this workaround is only applicable when you have many issues containing the same Custom Field value. Performing a bulk operation does not apply if you have many issues, and each issue has a unique Custom Field value.
- Create a new Custom Field.
- Using Advanced Searching, search for all the occurrences of the old field value.
- Using a bulk edit operation, you can populate the new field with the value of the old field for all the issues found using the search in Step 2. If editing of closed issues is disabled, you'll need to Allow editing of Closed Issues.
- Repeat this process for all other values that you are migrating to a new field.
- Delete the old field, or remove it from the screen scheme.
Changing Custom Field type via the database
This section involves making direct updates to the database that are not recommended by Atlassian.
Atlassian use SQL queries as a last resort for workarounds. Please note that editing the database or any XML backup is not supported by Atlassian.
There have been changes made to several custom fields which may mean this article is outdated and the below instructions may not work for JIRA versions 4.4+
More details on the field changes found here: Plugin Developer Notes for JIRA 4.4 - Single- and Multi-Select Custom Field Changes
Certain fields can be safely upgraded, such as Version and Select Lists to their multiple values counterpart. You can change the "customfieldtypekey" in the "customfield" table to whatever you need it to be. The table below lists the keys for commonly changed fields.
Custom Field Type | Type Key |
---|---|
Single Version | com.atlassian.jira.plugin.system.customfieldtypes:version |
Multi Version | com.atlassian.jira.plugin.system.customfieldtypes:multiversion |
Single Select | com.atlassian.jira.plugin.system.customfieldtypes:select |
Multi Select | com.atlassian.jira.plugin.system.customfieldtypes:multiselect |
Multi User | com.atlassian.jira.plugin.system.customfieldtypes:multiuserpicker |
For Select List, you need to remove the default value in your JIRA before you change the custom field type with the SQL below.
When moving from a Multi-Select List to a Select List, you have to make sure that only one item is selected for each multi select list.
When moving from Multi-Select to a Multi-User, you have to ensure that each select-list value is a username (cwd_user.user_name
value).
For Select Lists, you also need to update the "customfieldsearcherkey" field to use an appropriate searcher:
- For Multi-selects, use "com.atlassian.jira.plugin.system.customfieldtypes:multiselectsearcher"
- For Select Lists, use "com.atlassian.jira.plugin.system.customfieldtypes:selectsearcher"
- For Multi-user Pickers, use "com.atlassian.jira.plugin.system.customfieldtypes:userpickersearcher"