What If Jira Tickets Had an Expiry Date?

[#1]

After working with Jira for a few years, I started wondering about something strange.

Why do we archive emails, clean up old files, and delete unused applications, but we keep Jira tickets forever?

Every team I've worked with has thousands of old tickets sitting in the system. Some are closed, some are duplicates, some were never completed, and many haven't been opened in years.

The interesting part is that nobody questions it.

We spend a lot of time creating dashboards, workflows, automations, and reports, but very little time deciding what information no longer provides value.

A few weeks ago, I looked through some old issues from previous projects. Many of them referenced systems that no longer exist, people who had left the company, and requirements that were completely outdated.

It made me think: what if Jira issues had an expiry date?

Not for audit purposes or compliance records, but for everyday operational work.

Imagine a process where issues that haven't been touched in two years are automatically reviewed. Teams could decide whether they should be archived, merged, documented elsewhere, or simply removed from active visibility.

The goal wouldn't be deleting history.

The goal would be reducing noise.

One challenge many teams face is not finding information. It's finding the right information among years of accumulated information.

As Jira instances grow, search results become crowded, dashboards become harder to maintain, and teams spend more time filtering than finding.

Maybe the future of Jira administration isn't about adding more workflows and automations.

Maybe it's about deciding what no longer deserves a place in the workflow.

I'm curious to hear how other teams handle this.

Do you regularly review old issues, or do they simply stay in Jira forever?

[Sebastian Wigge]

The lack of your described feature forces us to do manual project/content reviews every once in a while. Luckily this became much easier with the introduction of Site Optimizer. Still, having a global system setting that automatically archives issues or entire projects after a set amount of time that can be decided by the customer would be a great time saver as well as a good way to reduce noise. I like the idea.

[Dennis Grochowski]

I totally get your point and also had multiple times the question on how to optimize search results and dashboards and always it falls back to "just filter it out". 

The performance in the Cloud is so good that hugh amount of items won't affect the user experience at all. Neither myself nor my users in the environment have ever described anything negative.

For users coming from other software it seems inconvenient to filter things away though.

You could use automations using api web request to archive the jql results without the need of waiting for Atlassian to gather enough interest implementing this.

But as of our internal research, people are mostly happy being able to search for historical data and other teams have possible compliance and data retention rules which strictly prohibits deleting or removing data at all. The range goes from marketing drafts which can be deleted, to support data which can be archived to legal requirements content which need to retain for a decade.

imho this is mostly a very department-related decision on how to proceed with the data and needs to be evaluated on individual basis. I don't think that a mechanism needs to be provided by Atlassian since everything is basically already there to build it if needed.

[Stephen_Lugton]

I'm actually going through old projects / work items as a background task at the moment seeing if there is anything sill relevant in them that will stop me from archiving them.

I'm doing the same with current projects, and I have some very simple Filters with subscriptions that email me regularly (monthly, fortnightly or weekly) with any items on specific projects that haven't been updated in the last 18, 6 or 3 months

[James Traxler]

Atlassian themselves could use it to review some of their outstanding work items for Jira itself, e.g. 

https://jira.atlassian.com/browse/JRACLOUD-4812 - created 06/Oct/2004, 2795 voters

https://jira.atlassian.com/browse/JRACLOUD-7302 - created 13/Jul/2005, 489 voters

https://jira.atlassian.com/browse/JRACLOUD-22506 - created 13/Oct/2010, 348 voters

[Rosana Casilli]

It is a good practice to archive old issues. I think that as a Jira Admin, after a little chat with project owners, we could decide the best way to achieve that. From my perspective and experience, not all project owners have the same historic baseline.
So, what I did:

• Talked with every project owner

• Decided how many historic issues should remain accessible (mainly because of Internal Audits). One criteria could be issues that have been closed for 1 year.

• Generated an automation to archive the issues and communicated the teams about this archive execution and how to recover those issues if necessary.

• Documented those decisions and the automation in a Confluence document.

[Carolyn White]

I am not a fan of auto archiving or deleting old work. There have been several times when a body of work was put on hold, sometimes for a couple of years, and we did not want to lose all the time we had already invested in thinking through the process. It was easiest for us to filter out that work in our project or board filters.

[Rune Rasmussen]

Depending on your specific requirements for GDPR, ISO, ISAE, or whatever, you could have a data retention policy along the lines of "Every work item created more than 5 years ago that hasn't been updated in more than a year gets auto archived/deleted".

And depending on the size and age of your setup it could be one global automation or multiple automation rules with different scopes.

You could also make room for exceptions, if a Space Owner can justify why some of their work items needs to be kept for a different period of time.