Move Projects (with Issue Data) [archived]


Moving project(s) between different Jira servers is a quite common scenario. The goal is that the project is transferred to the target Jira server fully transparently - with no loss of data or capabilities. The different parts of the projects that need to be transferred are:

  • configuration 
  • Scrum and Kanban boards
  • filters
  • dashboards
  • issues
  • issue links
  • comments, labels, worklog entries
  • attachments
  • Service desks and all related configuration
  • *apps, their configuration and data
  • all other user-defined data

Configuration Manager handles all of the above with the exception of some 3rd party apps' configuration and user defined data (preferences, favorites).

* Configuration Manager's support for issue data migration was developed from the ground up and does not rely on Jira's Export/Project import, meaning it does not inherit any of its limitations (including issue history, ranking, reports, links and other problems listed in the end of this article). 

Note: for best performance and to avoid potential OutOfMemory errors for large snapshot deployments make sure you increase the Java heap for your Jira. You can use the Jira sizing guide as reference, and double the heap numbers for very large deployments. A rough guideline is 32GB for moving a project with 100 000 issues (attachment files moved separately).

       ~ 1 hour              2 Jira Servers*              Project Snapshot              New Project Mode             Medium             Supported

*2 Servers are required. Production 1 (Source) and the Production 2 (Target) system.

Step by Step Diagram



This use case has several phases:

  • User Management Normalization
  • Project Configuration and Issues transfer
  • Apps Configuration and Data

User Management Normalization

Jira users, groups and roles are integral part of the Project Configuration - permissions, notifications, workflows, etc. Any users, groups and roles used in the project that you are attempting to move will be included in the project snapshot and during deployment, Configuration Manager will attempt to create them on the target server*. This will work for most cases, but might have the following limitations:

  • User with id johnsmith from the Source might already exist on the Target with different id - john.smith or jsmith for example. In this case Configuration Manager will create new user with id johnsmith which won't be accurate.
  • User with id johnsmith from the Source and the user with the same id on the Target might be a different actual user. In this case Configuration Manager will NOT create new user with id johnsmith which won't be accurate.
  • The users will be created and increase the user count which might have license implications.
  • The users/group creation might not be successful - due to the lack of a writable directory.

*As of version 4.1.1 and later Configuration Manager has the option to exclude changes in Roles on deployment, which means that users and groups referred only by roles will not be created on the target server. 

Project Configuration and Issues transfer

1. Source: Create a project with Issues snapshot for the project(s) you are moving, include all filters, agile boards and dashboards.
* Configuration Manager provides two ways to handle moving attachment files. Read more about Moving Attachments here.

2. Target: Deploy snapshot

    1. Use New Project deployment mode, provide project name and key, they should not match any existing projects. Note - if the snapshot includes multiple projects you won't be able to specify separate new project keys, instead CMJ will try to find matching projects on the target instance (by project key) and if there is no match for any project a new one will be created.

    2. Review the change and impact analysis in the Analyze step of the deployment. You will see that many new objects will be created (marked with Add or A icon ) and some configuration elements will be modified as well (marked with Modify or M icon). The modified elements appear because there are underlying configuration elements with the same name and type in the snapshot and in the Target Jira system. If some of the modifications are not desired, then the configuration on the Source system has to be modified and the process restarted.

      Usage of default schemes is not recommended. If they are used, the default schemes on the target server will be changed and this will lead to great number of changes.

    3. Review the issue import analysis page for the issues that will be added to the specified projects.
    4. Proceed with the deployment once the analysis shows the desired changes and impact.

App Configuration and Data

Several of the most popular apps in the area of custom fields and workflow extensions are supported by Configuration Manager. If the apps that you use are not listed, please contact our services team for other options. 


Automation of the above steps can be accomplished using the public REST API.