Botron Software

CMJ 101


Warning: mysql_real_escape_string() expects parameter 1 to be string, object given in /home/content/74/11756174/html/wp-includes/wp-db.php on line 1093

Move Projects

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

  • configuration
  • Scrum and Kanban boards
  • filters
  • dashboards
  • issues
  • all other user defined data
  • add-ons, their configuration and data

Configuration Manager handles the most complex part of this process – moving of the configuration from the source server to the target.

Duration ~ 1 hour             Environments 2 Jira Servers*             Snapshots Project Snapshot             Deployment ModeNew Project Mode            Difficulty Medium            REST API Supported

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

Step by Step Diagram

Steps

This use case has several phases:

  • User Management Normalization
  • Project Configuration transfer
  • Issues Import
  • Add-ons 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 lack of 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 transfer

1. Source: Create project snapshot for the project you are moving, include all filters, agile boards and dashboards. Check the option “Include custom fields with value in at least one issue”.


2. Target: Deploy snapshot

    1. Use New Project deployment mode, provide project name and key, they should not match any existing projects. Check “Do not create Versions and Components” – this is prerequisite for importing issues using Jira Project Import utility at step 3.
    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 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. Proceed with the deployment once the analysis shows the desired changes and impact.

Issues Import

Importing the issues into the Target Jira server can be accomplished with the native Jira Project import tool. This tool can successfully accomplish the task of importing the issues but has many known issues and limitations – check the limitations section on this page Jira Project import tool. In summary the following are the biggest issues:

  • Issue History problem – this is probably the most critical issue which makes the issue history unusable – https://jira.atlassian.com/browse/JRA-35604
  • Does not handle a case where there are multiple fields of the same type with the same name, the one with lower field ID will be used.
  • The “Agile Ranking” is not handled and the Agile board order won’t be preserved. Other Agile related issues – https://jira.atlassian.com/browse/JSW-13788https://jira.atlassian.com/browse/JRA-34338,
  • The “Agile Sprints” data won’t be imported if using Jira version lower than 7.0. –https://jira.atlassian.com/browse/JRA-28748
  • Any missing users will be created in the internal directory, if the User Management Normalization phase is successfully completed, this should not be a problem. If users are missing and cannot be created, then the import stops.  Note that if the ‘Do not merge changes in project roles’ option is selected, Configuration Manager will not try to create users and groups referred only by roles.
  • Any remote links including the ones to confluence pages won’t be handled https://jira.atlassian.com/browse/JRA-30460.

If you think that is something too risky or time consuming for you, please contact our services team for assistance.

Add-on Configuration and Data

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

Automation

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