Project Archiving
- Rosen Marinkov
- Stanley Neychev
On this page:
Description
Project archive is а very common scenario - when a project is moved to another Jira server which is used as an archive. The implementation of this use case is very similar to Move Project scenario.
Project archive 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 times 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 already finished projects may need to be restricted.
Full list of performance-tuning techniques can be found here:
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.
 | |||||
~ 1 hour | 2 Jira Servers* | Project Snapshot | New Project Mode | Medium | Supported |
*2 Servers are required. Production and Archive, the Archive server should be on the same version, have the same apps installed, and use the same user management settings.
Licensing
Two paid licenses are required, one for the Production instance and one for the Archive instance.
Steps
This use case has the following phases:
Project configuration and transfer of issues.
Delete the project from the Production Server.
Project configuration transfer
Source: Create a project with issues snapshot for the project you are moving, include all filters, agile boards, and dashboards.
Target: Deploy snapshot
a. Use New Project deployment mode, provide project name and key, they should not match any existing projects.
b. Review the change and impact analysis in the Analyze step of the deployment. You will see that many new objects will be created (marked with Add or A icon ) and some configuration elements will be modified as well (marked with Modify or M icon). The modified elements appear because there are underlying configuration elements with the same name and type in the snapshot and in the Target Jira system. If some of the modifications are not desired, then the configuration on the Source system has to be modified and the process restarted.
Usage of default schemes is not recommended. If they are used, the default schemes on the target server will be changed and this will lead to a great number of changes.
c. Review the issue import analysis page for the issues that will be added to the specified projects.
d. Proceed with the deployment once the analysis shows the desired changes and impact.
Delete the project from the Production Server
Once the project has been transferred successfully, it can be deleted from the production server.
Automation
Automation of the above steps can be accomplished using the public REST API.