There’s a metaphorical graveyard living in your Jira instance right now. Somewhere between the “In Progress” column and the depths of your backlog, there’s probably a ticket created three years ago about “Investigate potential performance improvements” that nobody’s looked at since the Great Refactoring of 2023. Maybe there are fifty like it. Maybe there are five hundred. I’m going to make a controversial statement, and I’m ready for the angry comments: you should probably delete most of them. This isn’t your typical productivity hack article that tells you to use better labels and implement more automation (though those things matter, sure). This is about recognizing that your Jira instance has become a digital hoarding situation, and like any good hoarder intervention, sometimes the healthiest thing you can do is throw things away. Let me explain why, and more importantly, how to do it without accidentally deleting the ticket that contains the only documentation for your critical payment system.

The Jira Ticket Problem Nobody Talks About

Your Jira instance is lying to you. Not maliciously—it’s just doing what it was designed to do. Every ticket you create gets stored forever, indexed, and made searchable. This sounds great until you realize that searchability without curation is just noise. When was the last time you searched through fifty irrelevant tickets to find the one you needed? When was the last time you saw a new team member open an old ticket, assume it was still relevant, and spend two hours investigating a problem that was already solved in 2024? When was the last time you had that sinking feeling that maybe, just maybe, you should check the ticket status before implementing something that might already be implemented? This is the ticket debt problem. And like technical debt, ticket debt compounds over time. The symptoms are:

  • Your backlog has thousands of tickets and you can’t remember why most of them exist
  • New team members ask “Is this still relevant?” more than they ask “How do I fix this?”
  • Filters are so complex that only three people know how to use them correctly
  • You have multiple tickets for the same problem, created by different people at different times
  • Your velocity metrics are meaningless because half your tickets are from projects that don’t exist anymore

Why This Happened (And Why It’s Not Your Fault)

Jira was designed as a persistent system of record. Everything goes in, and everything stays in, because you never know when you might need to find that one ticket from 2019 about that one edge case in the authentication system. This is a fundamentally conservative design philosophy—better to keep it than to lose it. But here’s the thing: that philosophy worked great when your team had eight people and fifty active projects. It breaks down when you have fifty people and two hundred projects and sixteen years of accumulated tickets. Most teams fall into a pattern: you create a ticket when something needs attention. You update it if you work on it. Then one of two things happens:

  1. You complete it and mark it done (maybe)
  2. It becomes permanently stuck in some half-finished state while higher-priority work comes in, and you eventually stop looking at it The problem is that category #2 is way more common than anyone wants to admit. And those tickets are like digital squatters—they’re not doing anything, they’re taking up mental space, and they’re actively making your system worse.

The Case for Radical Deletion

Here’s what happens when you delete half your tickets: Your filters start working again. Those JQL queries that return six hundred results? Suddenly useful. The “Needs Review” filter that showed everything three months old? Suddenly shows actual candidates for review. New team members stop getting confused. They open a ticket, and they can generally assume it’s something the team actually cares about. Revolutionary, I know. Your metrics become meaningful. Velocity, burndown charts, cycle time—all these measurements become actual data instead of noise. You can see if you’re actually getting faster at solving problems. You stop repeating yourself. With duplicate tickets cleaned up, you’re not solving the same problem twice and wondering why it’s broken again. Your backlog becomes a strategic document. Instead of “a place where work ideas go to die,” it becomes an actual representation of future work. This isn’t about being cruel to old tickets. This is about keeping your system honest.

What Gets the Axe?

Not everything should be deleted. You’re not running a scorched-earth policy. Here’s the framework I recommend: Delete tickets with extreme prejudice if they:

  • Haven’t been touched in over 18 months
  • Have zero comments, and the description is vague or unclear
  • Are marked as “Won’t Fix” or “Duplicate” and have been in that state for six months
  • Are related to products/projects that no longer exist
  • Propose changes to something already changed
  • Are “nice to have” features that no actual user has requested in the past year
  • Have been marked “Blocked” for longer than your team’s typical sprint cycle
  • Contain information that’s already documented elsewhere and more clearly Keep (and update) tickets if they:
  • Have active discussion and are being worked on or monitored
  • Represent known bugs in production systems
  • Are related to compliance, security, or regulatory requirements
  • Have been explicitly committed to in a roadmap
  • Have been referenced in documentation or architecture decisions
  • Are blocked on specific dependencies that might become unblocked Merge/consolidate tickets if:
  • Multiple tickets describe the same problem
  • A ticket is a duplicate of a newer ticket with better information
  • Subtasks are really just copies of the same work

The Step-by-Step Deletion Process (Don’t Panic)

This is where you actually do the thing. Here’s the process: Step 1: Export and backup Before you delete anything, export your Jira data. You can use Atlassian’s Data Center or Cloud export features, or use a third-party tool. Store it somewhere. You won’t need it, but you won’t miss it either.

# If you're using Jira Cloud's REST API, you can export issues
# Example: Get all issues from the past 18 months
curl -X GET "https://your-domain.atlassian.net/rest/api/3/search" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "jql": "updated < -18m",
    "maxResults": 1000,
    "fields": ["key", "summary", "status", "updated"]
  }' > backup.json

Step 2: Create filters for deletion candidates Use JQL to identify tickets for deletion. Here are some useful queries:

# Untouched tickets from old projects
updated < -18m AND assignee is EMPTY
# Duplicate markers
type = "Duplicate" AND resolution = "Duplicate" AND updated < -6m
# Won't fix tickets that are ancient
resolution = "Won't Fix" AND updated < -12m
# Everything in an archived project
project = "OLDPROJ" AND status != Done
# Stalled feature requests
type = "Feature Request" AND status = "Blocked" AND updated < -12m
# Low priority, never touched, explicitly marked as future work
priority = Low AND assignee is EMPTY AND labels = "future-consideration" AND created < -12m

Step 3: Review before delete Create a Jira filter for each deletion category. Share it with your team. Ask for feedback. Give people a week to object. This isn’t punishment; it’s spring cleaning. Step 4: Delete in batches Don’t delete all five hundred tickets in one go. Do it in categories, spaced out over time. This gives you a chance to realize if you accidentally deleted something important. For bulk deletion via the API:

# Get the list of issues to delete (using your filter)
curl -X GET "https://your-domain.atlassian.net/rest/api/3/search" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -d '{"jql": "your-deletion-filter"}' > issues_to_delete.json
# Delete each one (iterate through the results)
# Note: You need Delete permission and the ticket must not be linked to other issues
curl -X DELETE "https://your-domain.atlassian.net/rest/api/3/issues/{issueKey}" \
  -H "Authorization: Bearer YOUR_TOKEN"

Step 5: Archive, don’t delete (if you’re nervous) Some Jira administrators prefer to use labels and custom fields to mark tickets as “archived” rather than actually deleting them. Create a “status” of “Archived” and move tickets there instead. It takes up the same space but keeps your active backlog clean.

The Diagram That Changed My Life (And Maybe Yours)

Here’s what a healthy ticket lifecycle should look like:

graph TD A["Ticket Created"] -->|New ticket| B["In Progress"] B -->|Complete| C["Done"] C -->|Recent| D["Keep in Archive"] A -->|Unclear| E["Needs Clarification"] E -->|Resolved| B E -->|Not Needed| F["Delete"] B -->|Blocked| G["Stalled Status"] G -->|6+ months| H["Review & Decide"] H -->|Still needed| I["Update & Re-prioritize"] H -->|No longer relevant| F I --> B A -->|Duplicate| J["Consolidate"] J --> F style C fill:#90EE90 style F fill:#FFB6C6 style D fill:#ADD8E6 style I fill:#FFE4B5

Notice what’s missing? There’s no “forgotten in backlog forever” state. Because that shouldn’t be a state.

What Actually Happens After You Delete

This is the plot twist everyone needs to hear: you’ll probably be fine. Better than fine, actually. I’ve done this with three different companies now, and the pattern is always the same:

  • Nobody comes back asking about 90% of the deleted tickets
  • When someone does ask about a deleted ticket, it’s usually because they’re asking the wrong question, and the new conversation leads to a better solution
  • The team moves faster because decisions stop getting bogged down in “wait, didn’t we already do this?” conversations One company I worked with had a backlog of 3,200 tickets. They deleted 1,900 of them. Their velocity actually improved because time spent trying to figure out if something was relevant or duplicate disappeared.

The Uncomfortable Truth

Here’s what you won’t want to admit: if a ticket isn’t important enough to work on in the next six months, it’s probably not important enough to keep distracting you. This applies to the tickets themselves and, let’s be honest, to the organizational anxiety they represent. You keep them “just in case” because what if you need to remember that you once thought about implementing this feature? But you know what? If it was important enough to implement, someone will remember. Or they’ll file a new ticket with fresh context. And that ticket might have better information than the 2021 version anyway. The ticket isn’t a form of immortality for your ideas. It’s a task management system. When the task is irrelevant, the ticket should be too.

Making This Sustainable

Deletion is one-time surgery, but you need to prevent ticket gangrene from setting in again. Here’s how: 1. Set a deletion schedule. Once a quarter, review and delete stale tickets. Make it part of your process. 2. Establish a “maximum ticket age” policy. If a ticket hasn’t been touched in 12 months, someone should review it. Delete it, update it, or explicitly recommit to it. 3. Use board limits. Set WIP (Work in Progress) limits on your columns. Enforce them. If you can’t move a ticket to “In Progress,” you can’t create new ones. 4. Label strategically. Use labels like “backlog-priority”, “technical-debt”, “user-requested” to make future reviews easier. 5. Link like your life depends on it. Link related tickets so you can see dependencies and duplicates before they become problems. 6. Document decisions in tickets, not in the ticket description. Use comments to explain why a ticket wasn’t done. Use resolution fields clearly. Future you will thank current you.

The Objection You’re Already Having

“But what if we delete something we need later?” You won’t. And even if you do, you have backups. And even if you don’t, I guarantee you’ll solve the problem faster the second time with fresh context than you would by deciphering a cryptic three-year-old ticket written by someone who left the company. This is software development, not historical archives. Your job is to ship working software, not maintain a museum of past decisions.

The Bottom Line

Your Jira instance doesn’t need more features or better automation. It needs a diet. Start small. Pick one old project. Look at the tickets. Ask yourself: “Would I file this ticket today?” If the answer is no, delete it. Repeat. Your team will move faster. Your metrics will become meaningful. Your new hires will stop asking “Is this still relevant?” every five minutes. And your backlog will finally become what it was always supposed to be: a clear, honest list of the work your team actually intends to do. Everything else is just noise. So go forth and delete. Your future self, and your team, will thank you.