Skip to end of banner
Go to start of banner

WIP-Optimizing Migration Time for Large Jira Instances Using Configuration Manager for Jira (CMJ)

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Problem Statement

Migration of large Jira instances between data centers is challenging, especially when trying to complete the migration within a tight window such as a single weekend. Despite upgrading infrastructure and optimizing resources, the migration time using Configuration Manager for Jira (CMJ) has proven to be too long, especially with extensive data sets.

Symptoms

  • Extended Migration Time: Snapshot creation and deployment times are taking significantly longer than expected.

  • High Resource Utilization: Despite using high-tier compute resources, migration processes consume considerable time, especially during the snapshot creation and deployment phases.

  • Re-indexing Delays: The re-indexing process, particularly after deployment, adds additional time to the overall migration. For a large number of projects and issues, it is recommended to check the box Do not perform re-indexing during the deployment” to skip the re-indexing process after the issue data is imported. The deployment time will be considerably reduced, but re-indexing will need to be manually triggered afterwards.

  • Network and Storage Concerns: Possible network or storage latency issues could be affecting the performance of Azure Kubernetes Service (AKS) based deployments.

Root Cause Analysis

  1. Data Volume and Complexity: The source and target instances contain millions of issues, hundreds of workflows, custom fields, and attachments. The sheer volume and complexity significantly increase the time required for snapshot creation, deployment, and re-indexing.

  2. Single-threaded Operations: CMJ operations are single-threaded and do not leverage multi-threading or multiple database connections, limiting the ability to parallelize tasks and speed up the process.

  3. Re-indexing Overhead: Re-indexing after data import is time-consuming and substantially delays the overall process.

  4. Network Latency and Storage Performance: Possible network latency and suboptimal storage performance in the AKS environment could contribute to longer migration times.

Resolution

1. Optimizing Snapshot Creation and Deployment

  • Exclude Attachments from Snapshots: Given the large size of attachments, exclude them from the snapshot. Instead, migrate attachments separately, following best practices outlined in the Move Attachments.

  • Chunking the Migration: Instead of migrating the entire instance simultaneously, divide the data into smaller, manageable chunks. For example, split the projects into groups based on issue volume and migrate them sequentially. While not faster, this approach makes the process more manageable and allows partial completion within a weekend. Detailed guidance on chunking can be found in the How to deal with big snapshot deployments to optimize performance.

2. Improving Performance and Reducing Re-indexing Time

  • Skip Re-indexing During Deployment: To reduce time, skip re-indexing during deployment. Re-indexing can be performed manually after the data import is complete, as per the guidelines here.

  • Increase Compute Resources: Although already using high-tier resources, consider deploying a dedicated node in the AKS cluster exclusively for CMJ operations. This setup can isolate CMJ processes and potentially reduce bottlenecks caused by shared resources.

3. Addressing Network and Storage Performance

  • Local Storage vs. Network Storage: Evaluate the impact of storage type on performance. Moving to a VM with local storage may offer faster I/O operations compared to network-attached storage used by AKS. Collecting metrics and comparing these configurations can help identify the optimal setup.

4. Pre-Migration Preparation

  • User Normalization: Before migration, normalize users across source and target instances to minimize changes during the import. Detailed steps are available here Merge Jira Servers | First Stage Analysis.

  • Integrity Checks: Run both CMJ's and Jira's built-in integrity checks on both source and target instances. Fix any identified issues before initiating the migration. This step ensures that data integrity is maintained and reduces potential errors during migration. Detail steps are available here Integrity check

5. Using the CMJ REST API for Automation

  • Automate the Migration Process: Utilize CMJ's REST API to automate repetitive tasks such as issue key extraction, chunking, and snapshot creation. More information on automating these tasks can be found REST API Automation.

Conclusion

Migrating large Jira instances within a limited time frame is challenging but manageable with proper planning and optimization. The migration time can be significantly reduced by excluding attachments from snapshots, chunking the migration, skipping re-indexing, optimizing storage and network configurations, and leveraging automation. Implementing these best practices will help ensure a smoother and faster migration process.

For more detailed instructions and best practices, refer to the following resources:

  • No labels