I have test, staging and production Jira instances. Do I need a commercial license for each of them?
The Configuration Manager for Jira license must match the license of Jira itself. Usually, you'll need commercial license only for the production instance. Once you purchase a Configuration Manager for Jira license, you'll be able to generate development licenses for your test and staging instances.
If you have a commercial CMJ license, you can obtain dev licenses from my.atlassian.com as described here: https://www.atlassian.com/licensing/purchase-licensing?_ga=1.167884517.53990726.1485781377#licensing-7
Will Configuration Manager for Jira migrate issues between instances?
Yes, Configuration Manager for Jira supports issues since version 5.0.
Can I migrate Jira Service Desk projects with Configuration Manager for Jira?
Currently CMJ can move projects of type Service Desk along with their related standard Jira configuration objects, but doesn’t support any Service Desk – specific configurations (i.e. SLAs, queues, automation rules, etc. are not included in the snapshot).
After I migrated a Jira Service Desk project's standard configuration with Configuration Manager for Jira, it is unusable through the UI.
After the SD project is deployed with CMJ, it may not function correctly, because its specific configuration is missing. To fix this, you can change the project type to another one (say Business) and revert it to Service Desk. This will force Service Desk to populate the necessary configuration for this project.
Is it possible to use Configuration Manager for Jira to migrate a Jira project (with issues, filters, dashboards, Agile boards, attachments) if the source system is Jira Software 7.x and the destination system is Jira 6.x with Agile?
Configuration Manager for Jira allows this kind of deployment.
However, there are things that should be kept in mind. Jira 7.x has introduced configuration objects that do not exist on 6.x and if you have them in the snapshot you’re deploying the deployment will fail. Most of the configurations are around permissions (manage workflow permission), security levels (application role levels) and visibility permission for filters/dashboards (logged in user). So, to do a successful deployment you’ll have to remove any usages of these items in the source project’s configuration. A good way to do this is to replicate their instance in a test environment and try the deployment a few times until you resolve all issues.
That being said, if possible,we strongly advise you to first upgrade the target instance to at least the same version as the source. This would make the process much easier.