Incremental Аrchiving

On this page:

Introduction

For Jira projects that run continuously and generate thousands of issues, a periodic incremental archiving is required. Incremental archiving is a use case designed to enable organizations to periodically archive old issues and keep the performance of their production instance intact, whilst remaining compliant. 

Open

Archiving old Jira issues is typically driven by two main business needs:

Performance

• Over time the count of issues in Jira increases and this decreases the server performance. When this count is over 200,000, people are starting to experience longer wait time and certain specific tuning activities need to take place.

• Some of the common techniques to improve performance are:

  • Providing faster storage (SSD preferable)

  • Improving memory usage (avoid swapping, GC optimization)

  • Tuning the configuration (custom fields and permissions)

  • Decreasing the number of issues in the system - Project Archive essentially will decrease the number of issues and thus the system performance will improve. Over time this could mean hundreds of thousands of issues.

Security/Regulations

Access to old Jira issues may need to be restricted, but still available for auditing purposes.

The implementation of this case is very similar to Move Project and Configuration Manager for Jira handles the most complex part of this process - the move of the configuration and issues from the source server to the target.

Open

Steps 

This use case has the following phases:

1. Create a snapshot with the issues from the source you need to archive (production instance). Read more about filtering issues when creating snapshots.

2. Deploy on target (archive instance) as a new project with the same project name & key 

3. Delete archived issues from production 

Issues transfer from Source (production) to Target (archive)

1. Source (production instance): Create a snapshot of selected project issues.

2. Target (archive instance): deploy snapshot to archive instance

a. Review the change and impact analysis in the Analyze step of the deployment. If there are no configuration differences with the production instance, all should be good. In some cases, new configuration objects may be created (marked with Add or A icon ) and some configuration elements may be modified (marked with Modify or M icon). The modified elements appear because there are matched configuration elements with the same name and type in the snapshot and in the target Jira instance. If some of the modifications are not desired, there are several workaround options to consider:

• change the name of the modified element on the target (archive) instance to ensure the element won't be matched, or;

• change it on the source (production) instance and create a new snapshot, or;

• use an intermediate development instance where the snapshot is deployed and configuration element is renamed, a new snapshot is created and used for the archive

b. Review the issue import analysis page for the issues that will be added to the specified project.
c. Proceed with the deployment once the analysis shows the desired changes and impact.

Delete archived issues from production 

Delete all the old and already archived issues from your production instance. 

Subsequent incremental archiving differs a bit from the initial one. For future incremental archiving, please follow the following steps:

1. Create a project snapshot with issues of the project that needs archiving. Read more about filtering issues when creating snapshots.

2. Deploy the snapshot and merge with the existing project on the Archive Jira instance.

3. Delete the archived issues from the production instance.

Licensing

Two paid licenses are required, one for the Production and one for the Archive instance.

This use case license-wise is the same as the project archiving, and it explains how to archive any given project incrementally.

Automation

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