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:
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*
New Project Mode
*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.
Two paid licenses are required, one for the Production instance and one for the Archive instance.
a. UseNew 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 of the above steps can be accomplished using the public REST API.