Do you have any retention policies in Jira? If so, how do you implement them?

[Kraig]

Hi All,

Does anyone here have data retention policies they implement in Jira? If so, how do you implement these? I would love to hear what others are doing. 

[Mykenna Cepek]

The only data retention I've ever implemented (over a few small/medium sized companies) was for the weekly cloud backups.

Since we stored these elsewhere in the cloud (e.g. Box), having a defined retention plan helped in these ways:

• Clarity with leadership about what data will be kept (and when data will be deleted).
• Limiting the amount of data storage we would need.
• A crude method of monitoring data size (based on the backup file size).

A typical plan:

• Keep all weekly backups for the last 3 months.
• Keep 2 backups per month (1st and 3rd) for months 4-6.
• Keep 1 backup per month for months 7-12.
• Keep 1 backup per quarter for months 13-36.
• No backups older than 3 years.

I'd be interested in knowing the "Why?" behind your need for a data retention policy. Are there legal constraints to adhere to? Data storage limits? Just wanting to be tidy?

I'm also curious about the depth/granularity of the purging you envision. Project-level only? Issue-level? Certain data elements within issues (e.g. attachments, comments, etc)?

[Kraig]

Thanks for the info @Mykenna Cepek

The why is for a few combinations of things. One driver is that we've been operating on a Jira instance for >8 years, so the unneeded "cruft" has built up. (We don't need to save the fact that Jenny requested a new laptop back in 2013)

We've been exploring a retention policy to help clean things up and remove legacy unneeded data. We're looking at an initial sweep of unused projects with a goal of the remaining projects in our instance active, or recently active projects.

From there, implementing blanket retention policy of XX months on issues so that any issue not updated in XX months is deleted. 

[Mykenna Cepek]

Thanks for that info. A few further thoughts:

• You might want "XX months" to be > 12 or more, to ensure that you're not impacting any historical reports in Jira that might be useful to the teams.
• Confirm retention limits with the business. For example, does Sales or HR need longer retention than Support or Dev teams?
• All existing archived projects seem like low hanging fruit.
• I'd run through each project with a quick JQL search showing all issues sorted by "UpdatedDate" descending - the top result is the most recent update.
• Not sure if "LastViewed" might be helpful also (probably not). If using this, don't click into any issues in an old project. (I wouldn't use this)
• Eliminating all ancient projects first will help any remaining issue-level cleanup go faster.
• Automation can be used to delete issues matching certain criteria. But even as an Jira automation expert, I would be very reluctant to actually implement this.
• Instead, I'd probably use Automation to periodically scan and notify me when old issues pass some threshold (e.g. age, or quantity, or a combination). I'd then manually target those projects using JQL and then bulk-edit and delete. That would allow me to spot-check things. I'd add this to my weekly Jira maintenance, but maybe only actually perform it once a month.

It might be worth deciding whether you really want the hassle of dealing with individual issues. Or instead just wait until an entire project hasn't been touched in N years, and then delete the project. The latter would be much less work, and automation can still help you hunt for them.