Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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


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 @Niklas _bitvoodoo_,


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.)

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 _neusta portal services_ 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

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you