Skip to end of metadata
Go to start of metadata

Object Names That Differ Only In Case or Surrounding Whitespace

If the target contains objects whose name differs from names for 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 will be 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 that they have exactly the same name if they represent the same thing or clearly different names otherwise. Not only you will avoid import problems, but also end users will 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.