Summary

The following documentation provides workarounds for migrating supported custom fields that are currently blocked by the migration assistant.

Overview

When we are running a Jira migration through Jira Cloud Migration Assistant(JCMA), it's possible to encounter instances where certain Custom Fields fail to migrate, despite being supported as indicated on the What gets migrated with the Jira Cloud Migration Assistant page.

By examining the Post-migration report log from JCMA, you'll come across a specific message indicating the failure to migrate a Custom Field.

"The ""<CUSTOM_FIELD_NAME>"" custom field is not supported via migration. The value for this issue will not be migrated.","If you require this field value, use a csv import to update the issues post migration. See the 'Adding additional entities with CSV' section in this document: https://confluence.atlassian.com/cloud/what-gets-migrated-with-the-jira-cloud-migration-assistant-993925216.html"

If we are seeing the above error for the supported custom field, then follow the below section to migrate it.

How to Identify the Custom Field Type

1. Identify the name of the custom field from the above error log
2. Check if the custom field type is supported by the migration assistant with the help of documentation What gets migrated with the Jira Cloud Migration Assistant

3. This can be also checked from the database level, by executing the following database query on the server:

   select * from customfield where cfname = '<CUSTOM_FIELD_NAME>'

4. If the type matches one of these keys, then the field should be migrated:

   com.atlassian.jira.plugin.system.customfieldtypes:datepicker
   com.atlassian.jira.plugin.system.customfieldtypes:datetime
   com.atlassian.jira.plugin.system.customfieldtypes:textfield
   com.atlassian.jira.plugin.system.customfieldtypes:textarea
   com.atlassian.jira.plugin.system.customfieldtypes:grouppicker
   com.atlassian.jira.plugin.system.customfieldtypes:labels
   com.atlassian.jira.plugin.system.customfieldtypes:multicheckboxes
   com.atlassian.jira.plugin.system.customfieldtypes:radiobuttons
   com.atlassian.jira.plugin.system.customfieldtypes:multigrouppicker
   com.atlassian.jira.plugin.system.customfieldtypes:multiuserpicker
   com.atlassian.jira.plugin.system.customfieldtypes:float
   com.atlassian.jira.plugin.system.customfieldtypes:select
   com.atlassian.jira.plugin.system.customfieldtypes:multiselect
   com.atlassian.jira.plugin.system.customfieldtypes:cascadingselect
   com.atlassian.jira.plugin.system.customfieldtypes:userpicker
   com.atlassian.jira.plugin.system.customfieldtypes:url
   com.atlassian.jira.plugin.system.customfieldtypes:project
   com.atlassian.jira.plugin.system.customfieldtypes:version
   com.atlassian.jira.plugin.system.customfieldtypes:multiversion

5. If the type matches the above and still does not get migrated, then refer to the following section.

Root Cause

JCMA needs to satisfy two conditions to migrate a Custom Field:

• The type of the field must be supported.
• The field can't be blocked.

1. If the type is supported, then we should examine the managedconfigurationitem table to ascertain whether the field in question is listed as "blocked".

   SELECT * from managedconfigurationitem where cfname = '<CUSTOM_FIELD_NAME>';

2. This is a sample of an output with blocked fields, if we find the field in this table then it should be deleted before trying a new Migration Plan. 

   id,access_level,source,cfname,customfieldtypekey
   11115,LOCKED,com.pyxis.greenhopper.jira:reference-select-locked,<CF_NAME>,com.atlassian.jira.plugin.system.customfieldtypes:datepicker
   11116,LOCKED,com.pyxis.greenhopper.jira:reference-select-locked,<CF_NAME>,com.atlassian.jira.plugin.system.customfieldtypes:float

Solution

Delete the blocked field from the managedconfigurationitem table. We can use the following query to achieve that. 

delete from managedconfigurationitem where cfname = '<CUSTOM_FIELD_NAME>'