[All Adaptavist Apps]
If your target instance contains objects that have names that differ only in letter case or surrounding white space from other objects of the same type that are being imported, problems may occur during import. Examples of these differences can be issue type "Sub-task" vs "Sub-Task", or in surrounding whitespace as in "My workflow scheme " vs "My workflow scheme". In some cases, the import process will be able to recognize the difference and map both objects, but in others, these slight differences may cause the import to fail, due to inconsistent mapping of objects between the source and target instances. 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, it is recommended that you rename the implicated 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 your end users will also interact better with Jira. Consider their perspective when confronted with two different custom fields called "Reviewer" and "Reviewer ".
If a new custom field has to be created while importing, its required custom field type must be available at the target instance.
Therefore, 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 similar to the following:
Always run a simulated import before applying configuration changes to your target instance.
It provides an overview of the changes that will be applied to the target, included the objects that will be created or modified as well as warnings and any changes resulting in errors. This gives you the opportunity to refine the content of your import before committing any changes.