Configuration Import Errors
There are several things many users have difficulty with when trying to import configurations. This page will help target and alleviate those errors.
Object Names That Differ Only In Case or Surrounding Whitespace
If the target contains objects whose name differs from names of other objects of the same kind being imported only in the case of letters (for example, issue type "Sub-task" vs "Sub-Task") or in surrounding whitespace (as in "My workflow scheme " vs "My workflow scheme"), some problems may occur during import of the configuration. In some cases, the import process will be able to recognize the difference and map both objects, but in others, these almost coincident names may break the import, due to a non-consistent mapping of objects from the source to the target. This is more likely to happen when data import is run immediately after the configuration import (i.e., when importing complete projects).
In these cases, the best advice is to rename the involved objects, either at the source or target instance, so they have exactly the same name if they represent the same thing or clearly different names otherwise. Not only will you avoid import problems, but end users will also interact better with Jira—ask them what they think about having two different custom fields called "Reviewer" and "Reviewer "!
Missing App For a Required Custom Field Type
If a new custom field has to be created while importing, it is necessary that its custom field type is available at the target instance. This means that if the custom field type is defined in an app, this app must be installed and enabled in the target when the import takes place. Otherwise, the import will fail with a message like this:
Load failed for reason: Custom field type with key com.atlassian.jira.ext.charting:firstresponsedate not found. Check if it is defined in a plugin which is not enabled.