Annual Documentation Survey

Do you have 4 minutes to help us improve our documentation? Please take our annual survey!

Skip to end of metadata
Go to start of metadata

After selecting which projects will be exported, you need to choose wether exporting only the project configurations or complete projects




Export Options


At the top, there is a text box where you can specify the name for the exported file. The system will generate a default filename, but you can change it to suit your needs.

The exported file will have a default filename like this config-dump_BDI1-ZH19-A0IA-E1XU_PB.xml where:

  • It starts with a fixed string: config-dump_ for configuration only exports and project-dump_ for complete exports.
  • BDI1-ZH19-A0IA-E1XU is the server id of the instance where the export was run
  • PB is the key of the exported projects. If all projects in the instance are exported, this will be replaced by ALL. If more than one project but not all of the existing ones are exported, this will be replaced by XX_PROJECTS where XX is the number of projects included in the export (for example 20_PROJECTS)
  • The extension will be xml for configuration only exports and zip for complete exports.


This field is exclusive for complete exports.

If you select Automatic, Project Configurator will embed all necessary attachments for the selected projects into the same ZIP that contains the projects configuration and data.

If you select Manual, the exported ZIP will not contain any attachments, and you will need to move them manually to the target server before importing the projects.


The "Filtering custom fields" options selects whether all custom fields will be exported or only those that are used by the exported project(s). Detailed explanations about the criteria for deciding whether a custom field is "used" by a project can be found here.


The "User export options" is a list that lets you select one way to handle user data during export. Available options are:

  • Full export: This the default mode. When a user name is found anywhere in the exported configuration, the app looks for the user and adds its description to the exported items. If the user is invalid, the export will halt with an error.
  • Ignore invalid users: When a user name is found which is not valid, the user and its description are not added to the exported items. The user name still appears as component or project lead, or in a permission/notification/issue security scheme in the exported file. Export will not halt in these cases. Currently, the app is able to detect an invalid user name in two situations:
    • When it cannot find a user for that name.
    • When the found user has an invalid email address (it does not conform to the pattern "X@Y" where X and Y are non empty strings)
  • Do not export: No user will be exported, regardless it is valid or not. Export will not halt on an invalid user name.

"Group export options" offers the same choices for export of groups. Take into account that currently the only case detected as an "invalid" group is when a group cannot be found for a given name.


"Filter export options" lets you control export of filters. The choices are:

  • None (default): no filter will be exported.
  • Shared with all users: exports filters shared with all users will be exported.
  • Shared with exported projects: exports filters shared with one or all the roles of any of the exported projects.
  • With all users or with exported projects: exports filters that are shared with all users or with any of the exported projects. This  is equivalent to the union of the filter sets exported by the previous two options.
  • All shared filters: exports filters that have been shared with somebody else. This means that private filters, that are only visible to their respective owners, will not be exported.
  • All filters (shared or private): export all filters in the instance, either shared or private.

"Dashboard export options" offers the same choices for export of dashboards. Take into account that if you choose to export some or all dashboards but none of the filters, those filters that are used from dashboards will be exported anyway, so that the exported configuration is complete.


"Scrum and Kanban boards to export" acts in a similar way. It lets you select which Agile boards will be included in the export. The available options are:

  • None (default): no Agile board will be exported.
  • Associated to exported projects: Agile boards that are linked to any of the exported projects will be included in the export. Boards associated to a project appear under the project name at the project navigation panel (see an example image here).
  • All Scrum and Kanban boards: all Agile boards existing in the instance will be exported, regardless of their relation to the exported projects. This option will also export boards whose filter was deleted, even if these boards are not visible within Jira.
Export of Agile boards requires that Jira Agile plugin (in Jira 6) or Jira Software application (in Jira 7) are enabled. Otherwise, no Agile board will be exported (even if you requested something else).


What will happen when I load this configuration file?

When you are about to load a configuration file created with "Ignore invalid ..." or "Do not export" options, it is likely that it contains some references to users or groups (by their names) where those users/ groups are not included in the corresponding section of the configuration file. If a user/group with that name does not already exist in the target instance, there are some implications:

  • In some cases (e.g. users/groups are the default values in a custom field) and specially if the owner of a filter/dashboard is missing, the load will fail.
  • Even when the import does not fail, you are creating an inconsistency in your target instance. There will be a project, component, scheme,...using a user name or group name that does not correspond to a valid user/group.
  • No labels