Configuration Manager for Jira | Jira Sprint behavior during migrations
- Adriana Hernandez
- Rama Goberu
In this article, we’ll understand how the Jira sprint migration occurs considering two scenarios: deploying a snapshot as a new project and merging a project using Configuration Manager for Jira. Click here to see the summary table right away.
Considerations
When deploying a ‘project configuration with issues’ snapshot as a new project:
Active, inactive, and completed sprints objects are migrated correctly.
Issues that are migrated will have the corresponding sprint value set.
When deploying a ‘project configuration with issues’ over an existing project (merging):
If the same sprint is completed in the source instance but still active in the destination instance, CMJ will not complete the sprint when merging.
If the same sprint is active in the source instance but has not started (or is inactive) in the destination instance, CMJ will duplicate the sprint in the destination instance when merging if the source sprint has new issues. If the source instance sprint has no new issues, CMJ will still duplicate the sprint in the destination instance.
If the same sprint is active in the source instance but completed in the destination instance, CMJ will duplicate the sprint in the destination instance when merging if the source sprint has new issues. This duplicated sprint will be active in the destination instance. If the source sprint has no new issues, CMJ will still duplicate the sprint in the destination instance.
If there are two different sprints, one active in the source and the other active in the destination instance, once merged, there will be two different active sprints in the destination instance simultaneously (Parallel sprints).
Issues previously migrated to the destination instance will not be ‘updated.’ CMJ only migrates issues whose key does not exist in the destination instance. This means that if the issues in the source instance now have a different sprint value or workflow status, they will not be updated in the destination instance when merging. If you still need to update multiple migrated issues, you could delete them in the destination instance and then migrate them again with CMJ to visualize the last changes in those issues.
Scenario | CMJ Behavior |
|---|---|
Deploying a 'Project Configuration with Issues' Snapshot as a New Project | |
Active, inactive, and completed sprints | Migrated correctly to the new project. |
Issues with sprint values set | Issues will have the corresponding sprint value set correctly. |
Deploying a 'Project Configuration with Issues' Over an Existing Project (Merging) | |
The same sprint is completed in the source but active in the destination | CMJ will not complete the sprint in the destination. |
A sprint is active in the source but is not started in the destination | If the source sprint has new issues, CMJ will duplicate the sprint in the destination. If the source sprint has no new issues, CMJ will still duplicate the sprint in the destination. |
Sprint is active in the source but completed in the destination | If the source sprint has new issues, CMJ will duplicate the sprint as active in the destination. If the source sprint has no new issues, CMJ will still duplicate the sprint in the destination. |
Different sprints are active in both source and destination | CMJ will create two separate active sprints in the destination (Parallel sprints). |
More information about Jira sprints can be found in the following link https://confluence.atlassian.com/jirasoftwareserver/running-sprints-in-a-scrum-project-938845426.html.