Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

JIRA Server - Archiving Best Practices


Hello Community,


For me, this is one of the least defined topics as I have not had experience and frankly, there is no unified go to approach yet.

In recent JIRA Versions, as far as I know there is no such "limit" which cannot be breaked and I know that optimization is much more efficient than total issue number.


Having said that, there will be a near time for me , where the need for archiving would arrive.

Current instance stats:


JIRA DB Stats as of 14 May 2018.JPG


"Archived" Projects, which generally I have mapped to a permission scheme, accessible only for audit and reporting users, are a good thing, but still all issues are loaded in lucene indexes.

Partial indexing of issues would be a good improvement, but I don't think it would be the only one needed as I'm sure the performance stretches further than just indexes.


I would like to get your feedback on:

Which is your favorite Archiving Policy, assuming you have one ?

Do you have any go to strategies for better "archive" optimizations?


Best Regards


Sloan N_ B_ Community Leader May 14, 2018

Hey @Gezim Shehu [Communardo]

You already mentioned the current best practise for (online) archiving Jira projects. 

Additionally I sometimes partly archive projects with the help of Issue Security Levels.

But apart from hiding projects and issues with Permission Schemes or Issue Security Levels, there is not much archiving out of the box.

With instances getting as big as yours I can imagine that something "real" is needed.

On the marketplace seem to be a hand full add-ons. But I never tested them.


Hi @Sloan N_ B_,


Yeah it's definitely gonna need an offline archive sometime soon.

Unfortunately I too haven't found any solution or best practice for this.


Loading project by export all instance and importing one project only at an offsite backup may be a valid option, but still not optimal.



Have you considered exporting your issues from Jira, then permanently deleting them from Jira? This would ultimately decrease the load on Jira.

For example, using the PDF View Plugin you could export them to PDF files, in which you have full control what fields to include, whether to include comments, attachments (even their binary content!), change history, links, etc.

Here is a couple of samples.


Then you could put these documents to any document management system which can index them for future searches.

The drawback of this approach is that it does not enable easily restoring issues from the archives, although I am not sure if that is a requirement here. (You could still restore issues manually from the PDF if there is an infrequent need for that. Or even write a script that parses the content from the PDF and creates the issue via the Jira REST API.)

This has been discussed also here, maybe there is some interesting information for you.

Hi @Aron Gombas _Midori_,


That sounds a great option, though not applicable for my situation.

I am leaning more towards an "backup" instance where :

1-Either all the issues are stored

2-After successfully testing the solution, only export backups from Production and use this as a restore instance for audit/investigation only.



@Bastian Stehmann Hi,

Thanks I'll check it out


Best Regards

Still though, the Customer Portal is an issue, as ultimately customers and approvers require the full history to be present.


Log in or Sign up to comment