Skip to end of metadata
Go to start of metadata

You may find some issues during the migration. Here, you will find tips for dealing with them.

First of all, take into account that the full migration process has a step where the source configuration is imported to the destination instance, so the pages about typical issues found when exporting or importing configurations may be useful also when you are migrating complete projects.

Also there some known problems which may affect specifically data import. These are explained in this page.

Custom Field Context That Applies Only to Some Issue Types

Sometimes data import will fail with a message like this:

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.

You get this error even though the custom field is actually applicable for those issue types at the destination instance. This is a result of the bug, JRASERVER-28006. The workaround for this issue means making the custom field available for all issue types. So follow these steps for fixing it:

  1. In the target instance, make the field available for all issue types. See Configuring a custom field for more information. 
  2. Repeat the import. Make sure to select "Custom fields" as entities to be ignored in the configuration import in the import options. Otherwise, the app will reapply the configuration to custom fields as it comes from the source, undoing your manual adjustment in step 1.
  3. After a successful data import, you could restore manually those custom fields to their original configuration (restricted to some issue types) if that is the way you want them to be. Bear in mind, you could also achieve this restoration, exporting "configuration only" 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 destination. Of course, in this case, do not skip the import of custom fields.

Validation Error Without Any Further Information

Sometimes you might find a validation error without any specific information. as in:

WARN  11:00:56,968 The attachment '' 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.

You also examine the Jira log file, but that does not throw any additional light on 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 destination. See point 3 in the section named "Matching properties of both instances" in Atlassian's Preparing for migrating projects.

Values for "Time in Status" Custom Field

Sometimes you will find a warning like this in the data import trace:

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 just means that values for that custom field will not be imported. The reason is that 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 Jira Charting Plugin and its values are calculated automatically from the story of issues included in graphics, so it is not an issue if these values are not imported: they will be recalculated again as needed.

No Timezone Information in the Exported Data

The exported data will certainly 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 these bug reports  JSWSERVER-5433 - Restoring Sprint data in a different server timezone broken Resolved  and  JRASERVER-26039 - Verify the system timezone when an XML backup is restored Resolved

The workaround: make sure that source and target instances are using the same timezone.

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

In this case, the data import fails with this message, that means a number inside square brackets is not a valid string representing a number.

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

java.lang.NumberFormatException: null within SprintImportHandler

This is seemingly a very similar error to the previous one but in fact a completely different thing. It occurs while importing Sprint data as can be seen at the top of the error trace:

Data import failed with exception: null
java.lang.NumberFormatException: null
at java.lang.Long.parseLong(
at java.lang.Long.valueOf(
at com.atlassian.greenhopper.imports.SprintImportHandler.endTable(

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 how to fix it.

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 nicely with the feature in Project Configurator that migrates Scrum or Kanban boards, as part of the project configuration, providing a complete solution for the migration of Jira Software projects.

However, there is a problem when there are sprints that include issues for more than one project. In this situation, these sprints will be duplicated (one sprint will be created for each project involved) and the ranks will only keep the relative order among issues belonging to the same project. This is a result of the underlying data transport technology importing one project at a time. Project Configurator just 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 that would fix the exported data. Bear in mind that:

  • That fix is explained for an XML backup. Remember that if you have exported with PC the "" file will be found 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.
  • This fix is quite complex.