The Jira Cleanup Guide

Why Jira cleanup matters more than it looks

Dirty Jira instances do not only look untidy. They create concrete operating drag:

• access reviews take longer because nobody trusts the current model
• offboarding takes longer because stale permissions and stale groups blur the real access path
• migrations get slower because the team is carrying junk it does not want to rationalize
• renewal conversations get noisier because user counts and project sprawl mix together
• admins postpone cleanup because every change feels like it could break something obscure

Atlassian's own migration guidance is blunt about cleanup before Cloud moves: cleanup reduces migration complexity, smooths test runs, and helps avoid carrying unnecessary data and configuration forward. The same logic applies outside migration. The more stale structure you leave in place, the harder every future review becomes.

The five cleanup lanes

The mistake is not having too much to clean. The mistake is assuming it is all the same kind of work.

1. Users

This lane covers:

• inactive people
• leavers
• contractors whose access should have expired
• users who no longer need the app
• service or non-human identities mixed into human review queues

This is the most visible cleanup lane, and the one teams usually start with. Atlassian's billing documentation makes the financial consequence clear: users added to an app are counted toward billing even if they never accept the invite or log in. That is why stale user cleanup gets so much attention.

But user cleanup also has traps. Removing a person from Jira is not the same as deleting their identity everywhere. Suspending or removing access affects billing and app access, but it is still a different decision from deleting a managed account entirely. If you skip those distinctions, cleanup becomes sloppy fast.

2. Groups

This lane covers:

• old groups nobody claims
• overlapping groups doing the same job
• legacy groups kept alive by habit
• renamed organizational structures that never got reflected in Jira
• default groups that are granting more than admins realize

Groups are dangerous cleanup objects because they sit between identity and access. Atlassian's user-management model uses groups both for app access and for reusable in-app permission references. So a group is never "just a label." If it is still wired into permission schemes or roles, group cleanup is really access cleanup.

3. Permissions

This lane covers:

• stale permission schemes
• overly broad permissions left behind by old operating models
• permissions granted directly to groups that no longer match the current org design
• schemes copied years ago and never simplified

Permission cleanup feels abstract until you remember that permission schemes can be shared. One stale scheme decision may affect several projects. That is why permission cleanup should almost never be the first cleanup step. If you clean permissions before you understand the users and groups behind them, you are just editing blind.

4. Project roles

This lane covers:

• roles with outdated membership
• roles used where groups should have handled the identity layer
• roles that still reference old teams, owners, or contractors
• inconsistent role models across projects that should be standardized

Project roles are not the same as groups. They are contextual placeholders inside projects. That makes role cleanup partly technical and partly organizational. You are not only removing a reference. You are clarifying who is supposed to do what in that project now.

5. Old projects

This lane covers:

• genuinely abandoned projects
• projects that should be archived
• projects kept around for historical reasons but still carrying active permissions
• project containers that outlived the team or process they were created for

Old projects are tempting cleanup targets because they are visible and satisfying. But they should usually come later in the sequence. Why? Because old projects often preserve stale roles, stale permissions, and stale groups. If you archive or delete the project without understanding those relationships, you may lose context you still needed for broader cleanup decisions.

The cleanup order that actually works

A practical Jira cleanup sequence looks like this:

1. Build inventory before changing anything.
2. Clean users first.
3. Review groups next.
4. Review permissions and project roles after the identity layer is clearer.
5. Handle old projects last, once the access model is better understood.

That order matters because it reduces ambiguity as you move down the stack.

Step 1: Build a real inventory

Before cleanup turns destructive, you need a current picture of:

• who has app access
• which groups are used to grant that access
• which permission schemes are shared
• which projects carry old roles or old ownership models
• which projects are active, dormant, archived, or candidates for retirement

This does not need to become a six-week governance program. But it does need to be concrete enough that you can sort items into lanes instead of blending them into one vague cleanup backlog.

If you skip inventory, everything later becomes opinion-based. That is when teams start arguing over whether a group "probably isn't used anymore" or whether a project "looks old enough to archive."

Step 2: Clean users first

User cleanup is the right first pass because it clarifies who actually needs to exist in the access model.

At this stage, ask:

• who still needs Jira access at all?
• which users are inactive, suspended, or clearly out of scope?
• which rows are non-human identities and should not be processed like normal leavers?
• which users remain billable because of visible access paths that still need review?

Atlassian's default-group behavior matters here. Users can be automatically added to default groups when app access is granted, and Atlassian explicitly notes that this can lead to unintended license consumption if not configured carefully. That means user cleanup is not only about people. It is also about the access model that keeps them billable.

For pure user cleanup, Jira User Management for Growing Teams and The Hidden Cost of Inactive Users in Jira and Atlassian Cloud are the most relevant follow-ups.

Step 3: Review groups after the user layer is clearer

Once the user picture is less noisy, group cleanup becomes far easier.

Now you can ask:

• which groups are clearly obsolete?
• which groups still grant app access?
• which groups still appear inside permission schemes or project roles?
• which groups are default groups that need more deliberate control?
• which groups are externally managed and therefore not suitable for ad hoc admin cleanup?

This is the point where many teams stall. A stale group looks harmless until someone realizes it still appears in live permissions somewhere important. That is why pre-change review matters more than speed. For this lane, the best follow-up is What to Review Before Deleting or Renaming a Jira Group.

Step 4: Clean permissions and project roles only after identity review

Permissions and roles come later because they sit on top of people and groups. If the underlying identity picture is still messy, editing schemes and roles too early creates false confidence.

At this stage, look for:

• permission schemes that are broader than current operating needs
• shared schemes nobody is treating as shared
• roles with unclear owners
• roles being used where group membership is doing the real work
• duplicate access paths that make cleanup harder to explain later

This is where the distinction explained in Jira Permissions Explained and Jira Project Roles vs Groups becomes practical instead of theoretical.

Step 5: Review old projects last

By the time you reach old projects, you have a cleaner understanding of:

• who still needs access
• which groups still matter
• which roles still carry live meaning
• which schemes are shared and which are project-specific

Now you can make better decisions:

• archive if the project should remain as history but should not stay active
• delete only when retention and context requirements are satisfied
• preserve if it still supports an active process
• split or rationalize if one bloated project is really several different legacy problems

Old projects are important, but they should not dominate the cleanup sequence. They are usually the final structural decision, not the first.

What people often miss

Cleanup is not one problem

This is the biggest miss. "Jira cleanup" sounds singular. It is not. User cleanup, group cleanup, permission cleanup, role cleanup, and project cleanup have different risk profiles and should not be forced into the same one-size-fits-all workflow.

Default groups quietly distort both access and cost

Default groups are one of the least glamorous parts of Jira admin work and one of the most consequential. They sit right at the intersection of access and license consumption. If you ignore them, you will keep rediscovering why seats remain active or why new users land in places you did not expect.

Shared schemes create invisible blast radius

One scheme edit can affect several projects. One group change can fail to remove access if there is another path. One archived project may still be carrying the old pattern you should have fixed more systematically. Cleanup feels bigger than it is because the objects are connected.

Manual cleanup breaks down at the proof stage

At small scale, manual review is annoying but possible. At larger scale, the real failure is not finding the item. It is proving the review was complete enough for someone else to trust. That is where spreadsheets, screenshots, and admin memory start to fail.

A practical cleanup matrix

Where focused tools start to matter

There is a point where cleanup stops being "can I check this?" and becomes "can I review it without missing something important?"

That split matters because the two products solve different cleanup lanes:

• If the problem is pre-change group review, shared permission impact, or safer evidence before touching a group, start with the Jira group cleanup use case, then compare native Jira review vs Group Impact Audit for Jira. The product route in this repo is Group Impact Audit for Jira.
• If the problem is billable access, inactive-user review, renewal cleanup, or getting out of spreadsheet-heavy seat review, start with the Atlassian license renewal use case, then compare spreadsheets vs License Guard and review License Guard.

The key is to choose the workflow that matches the cleanup lane. Do not throw one generic cleanup process at everything.

Next steps

If your cleanup work is broad and you need to sequence it:

• read Jira User Management for Growing Teams for the lifecycle lane
• read What to Review Before Deleting or Renaming a Jira Group for the action-stage group lane
• read The Pre-Migration Jira Cleanup Checklist for Cloud Moves if a migration deadline is forcing cleanup now

The fastest cleanup teams are not the ones deleting the most objects. They are the ones reducing ambiguity in the right order.

FAQ

What should a Jira cleanup start with?

Start with inventory and users. You need to know who actually needs access before you can make clean decisions about groups, roles, schemes, and old projects.

Should you clean users or groups first?

Usually users first. That removes noise from the access model and makes group review far easier to interpret.

Is it safe to archive old Jira projects?

Sometimes, but not blindly. Review whether the project still preserves active permissions, stale ownership models, or historical context you still need before archiving.

How often should Jira cleanup run?

That depends on scale and change rate, but recurring light cleanup is almost always safer than rare panic cleanup before migration, renewal, or audit.