JCMA doesn't migrate all Custom Fields

Summary

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

Diagnosis

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.

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

How to Identify the Custom Field Type

1. In the migration report, note the exact custom-field names flagged as not migrated.

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 also be 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. Check whether each is provided by a Marketplace app — if so, install/configure that app on the destination first, then re-run.

6. For locked fields, recreate manually on the destination and map values post-migration.

7. If the type matches the above and is still not migrated, 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, we should examine the managedconfigurationitem table to determine whether the field in question is marked as "blocked".

   SELECT * FROM managedconfigurationitem WHERE item_id IN (SELECT concat('customfield_', id) FROM customfield WHERE cfname = '<customfield_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.

How do I know it worked?

A rerun's report shows the previously missing fields as migrated (or you've confirmed the app recreated them).