Best practices for Configuration Manager for Jira

On this page, you can find many of the best practices that we recommend you use when working with Configuration Manager for Jira (CMJ). Our list includes a wide array of cases, but if these best practices aren't enough to help you with your specific issue, then be sure to contact us at the support portal.

Category	Use case	Best practice

Category	Use case	Best practice
General	Prerequisite or setup confusion	Be sure to go through our Use Case documents and identify which one meets your current needs. Often, following the prerequisites and setup instructions in these documents is enough to clarify some users' confusion.
Jira management	User normalization	CMJ does not support user normalization. Therefore, we recommend that you ensure that users and groups are properly set in advance on the target instance before migration starts.
Data Center	Platform benefits	Be sure to properly take advantage of all the benefits a data center Jira system provides. For example, having a well-set-up dedicated deployment node can help you speed things up.
Migration	Memory allocation	When exporting or importing snapshots, you must have enough system memory allocated on your Jira to correspond with its size. You can refer to the Jira sizing guide and Jira application memory pages for more details.
	Tons of issues	If you have one or more projects with tons of issues (100K+), you will benefit from splitting your deployment into multiple snapshots. This approach is not necessarily faster, but it will help make the migration more manageable. You can migrate as much as possible during your migration window and still have a working system with a portion of the projects and issues afterward.
	High attachment volumes	If you have a lot of attachments within your issues (roughly more than 100 MB per project), then you can speed up your migrations by not including the attachments in your snapshot exports. You can add them later by providing their location path during a snapshot import, or you can skip them altogether.
	Moving archived projects	Archived projects and issues should be moved separately. After all, they are not currently used and can be migrated at any time, even during working hours. Also, it's a good practice to regularly archive inactive projects and issues to save space and to have smoother migrations.
Post-migration	Reindexing	Don't perform CMJ's reindexing as part of the import process. Rather, do it manually after the import is complete. This way, you won't slow down the deployment, and you can trigger the reindexing when it's most appropriate for your organization.