Project Configurator for Jira Server and DC

Project Import Errors

This page aims to help you anticipate potential migration issues or resolve them if they do occur. If you continue to encounter errors after identifying the cause and resolving the issue, you can consult our Project Configurator Knowledge Base for searchable how-to and troubleshooting articles. If troubles persist, please submit a request through our Support Portal. We will be very glad to help!

Firstly, consider that the full migration process includes a step where the source configuration file is imported to the target instance. Our exporting or importing configurations errors pages may therefore also be useful even when you are migrating complete projects.

The following sections reference some common problems which may specifically affect data import.

Custom Field Context That Applies Only to Some Issue Types

Sometimes a data import will fail with a message similar to the following:

The custom field 'XXXX' in the backup project is used by issue types 'AAAA, BBBB' but the field with the same name in the current JIRA instance is not available to those issue types in this project.

This error occurs even though the custom field is actually applicable for those issue types at the target instance. This is a result of bug, JRASERVER-28006. The workaround for this issue is to make the custom field available for all issue types by completing the following steps:

  1. In the target instance, make the field available for all issue types. See Configuring a Custom Field for more information.

  2. Return to the Import Projects screen, then select Custom Fields as objects to be skipped using the Skip Configurations option before running the import process again. Otherwise, the app will reapply the configuration to custom fields from your original source file, undoing your manual adjustment you made in Step 1.

  3. After a successful data import, you can manually restore those custom fields to their original configuration (restricted to some issue types) if required. Alternatively, you could achieve this restoration by exporting only your project configurations from the source instance, or extracting the config.xml file from the ZIP file you are importing, and then importing that configuration file into the target. In this case, do not use the skip import of custom fields option described in Step 2.

Validation Error Without Any Further Information

Sometimes, you might receive a validation error without any specific information, similar to the following:

WARN  11:00:56,968 The attachment 'MMMMMMMMM.zip' does not exist at '/tmp/com.awnaba.projectconfigurator1493567880435/data/attachments/XXXXXXXXXXX'. It will not be imported.
WARN  11:00:56,968 The attachment 'screenshot-1.png' does not exist at '/tmp/com.awnaba.projectconfigurator1493567880435/data/attachments/YYYYYYYYYYYY'. It will not be imported.
WARN  11:00:56,968 The attachment 'screenshot-1.png' does not exist at '/tmp/com.awnaba.projectconfigurator1493567880435/data/attachments/ZZZZZZZZZZZZZ'. It will not be imported.
INFO  11:00:56,969 Project Import: Validation errors were found. The import cannot continue.

The Jira log file may also not provide any additional detail for the issue. In our experience, this problem is usually caused by a value for a text field that exceeds the limit for maximum text field size at the target instance. See point three in the Matching Properties of Both Instances section in Atlassian’s Preparing for Migrating Projects page.

Values for Time in Status Custom Field

You may encounter a warning in the data import trace similar to the following:

WARNINGS: Unable to import custom field 'Time in Status'. The custom field type does not support project imports.

This message is a warning; it will not stop the import. It simply means that values for that custom field will not be imported because the custom field type does not support data imports, as it does not satisfy the requirements defined in Atlassian’s How to Make a Custom Field "Importable" for Project Imports page.

However, to the best of our knowledge, this is not relevant in practical terms. That field belongs to the Jira Charting App, and its values are calculated automatically from the story of issues included in graphics. If these values are not imported, they will be recalculated again as needed.

No Timezone Information in the Exported Data

The exported data will contain date/time fields but no reference to the timezone where those values are valid. As a result, if the source and target instances use different timezones, the time values will be shifted by the time difference between those zones. See the following bug reports:

  • JSWSERVER-5433 - Restoring Sprint data in a different server timezone broken

  • JRASERVER-26039 - Verify the system timezone when an XML backup is restored

The workaround is to ensure that your source and target instances are using the same timezone.

java.lang.NumberFormatException: For input string: "[99999]"

With this error, the data import fails with this message which explains that a number inside square brackets is not a valid string representing a number.

Usually, this is a consequence of bug JRASERVER-59681. The bug ticket from Atlassian explains how the import can be fixed.

java.lang.NumberFormatException: null within SprintImportHandler

This error occurs when importing Sprint data, as shown at the top of the error trace:

Data import failed with exception: null
java.lang.NumberFormatException: null
at java.lang.Long.parseLong(Long.java:552)
at java.lang.Long.valueOf(Long.java:803)
at com.atlassian.greenhopper.imports.SprintImportHandler.endTable(SprintImportHandler.java:105)
at com.atlassian.jira.imports.project.ao.handler.ChainedAoSaxHandler.endTable(ChainedAoSaxHandler.java:263)
at com.atlassian.jira.imports.project.ao.handler.ChainedAoSaxHandler.endElement(ChainedAoSaxHandler.java:190)
at com.atlassian.jira.imports.project.ao.handler.ChainedAoSaxHandler.endElement(ChainedAoSaxHandler.java:151)

The Jira knowledge base article, Project Import Fails with Unexpected Import Failure, describes this issue, points to the bug ticket with the root cause, and recommends a solution.

Sprints Across Several Projects are Duplicated

Starting with Jira 7, sprint and ranking data is migrated with the rest of the project data. This works well with Project Configurator’s feature that migrates Scrum or Kanban boards as part of the project configuration, providing a complete solution for the migration of Jira Software projects.

However, problems can occur when there are sprints including issues for more than one project. In this case, these sprints will be duplicated—​one sprint will be created for each project involved—​and the ranks will only maintain the relative order among issues belonging to the same project. This is a result of the underlying data transport technology that imports one project at a time. Project Configurator calls this process once for every project to be imported.

DataAccessException Occurred While Trying to Create Entity Type 'EntityProperty'

This problem is described in Project Import Fails Due to too Many Errors. This article also explains a workaround to fix the exported data. Bear in mind that this fix is quite complex, and is defined for an XML backup. Remember, if you have exported with Project Configurator, the data.zip file will be located under the data folder in the exported ZIP. After changing it, the edited version must be compressed back into the same location in the exported ZIP.

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.