If your configuration is very large, it may be more convenient to spit the import into several shorter stages.
The import is split by selecting different object types to be ignored or skipped each time. The selection of object types to skip in each stage must take into account the dependencies that may exist between different object types. For example, workflow schemes link issue types with workflows, so it makes sense to import issue types and workflows before workflow schemes. To help you identify where objects are used in your instance, you can run the Object Dependencies report.
Dependencies include workflow conditions, validators, and post-functions used, including those defined in supported workflow apps.
For a given configuration, you cannot import one of the object types in the first column in the table below if the object types in the second column have not already been imported. Consider also that the requirement is for the referenced object to exist in the target instance. It is not necessary that it has the exact configuration as defined in the XML file.
Projects included in the XML configuration file are always created with a default configuration, including default schemes, therefore you cannot skip the creation of new projects.
Issue link types (1)
Issue types (1)
Custom fields (1)
Project roles (1)
Issue type schemes
Field configuration schemes
Issue security schemes
Issue type screen schemes
|Issue type screen schemes|
|Issue type schemes||Issue types|
|Issue security schemes|
|Issue link types|
|Field configurations||Custom fields|
|Field configuration schemes||Field configurations|
It is recommended that you test the import on a test instance to verify that the split files import as expected.