nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Looking for Cleanup/Archiving Best Practices

Mirek

Hello,

I know many customers (especially those larger ones) dealing with a growing number of objects (e.g in Jira instance—projects, issues, custom fields, workflows, etc.—and are starting to see manageability challenges.

I’m very interested in hearing from other organizations who’ve tackled similar problems. Specifically:

Do you follow a regular cleanup schedule (monthly, quarterly, yearly)?
What archiving strategies or policies do you use (e.g., for inactive issues/projects)?
Are there any tools or automation you’ve found helpful?
How do you get buy-in from stakeholders to clean up or archive data?
Any lessons learned or mistakes to avoid?

Any insights, processes, or even small tips from your own experience would be really appreciated!

Comments

Caleb Youngblood

Hello!

This is also something I'm interested in. We currently don't follow a regular cleanup "schedule", we have just periodically raised tickets to see certain objects change or be removed. That being said, we are currently undergoing a first-ever iteration of closely examining every object in Jira, and ensuring that it has a purpose.

Regarding archiving strategies, I encourage our organization to pursue a minimal data configuration. If a project has been inactive for a year, remove it. If issues are raised, with no resolution, close it. Data quality is very important.

Recently, we have invested in Salto for Jira, a tool that makes these problems much easier to navigate. Highly recommend you check it out.

Marco Nowak_g3wnkz

Hello @Mirek .

We do regularly clean ups. When we recognize that there is an unused project or custom field etc we ask the owners if they still need them or if we can either archive them (using the default archiving feature) or even delete them.

In general we have a policy that JIRA is not our archiving system and therefore we offer stakeholders to store data up to X years and delete them automatically by using JIRA automations.

Lessons learned for customfields or even workflows: we try to keep these as general as possible so that they can be reused by other projects.

For custom fields we use the description beneath the field name to customize them per project using field configurations. E.g. a stakeholder needs a field "Invoice Category" we would create a custom field named "Category" and do the customization by adding the description "Invoice Category" using field configurations. The custom field "Category" can the be reused by other projects the same way. This will reduce the amount of custom fields.

rgds

Marco

Tanya Christensen

@Mirek There are a few Atlassian support pages on the topic:

Atlassian has a service that can help guide you through the clean up effort: Advisory Services Catalog and click on "Configuration Health Check & Optimization".

One key thing I express to customers is to offload Jira projects and Issues so true clean up can be completed. If you have archived projects and issues they are still tied to fields, schemes etc and you can remove those.

Routine clean up practices are critical to keeping a performant instance/site and will ensure a good user experience, not only for the end users but the Jira admins as well. Who wants to wade through 1000 workflow schemes? Not me.

Yes, do work with power users and key stakeholders to agree upon which should remain and which should be deprecated. Inform all users of this plan and then execute the removal. .

Several Marketplace Apps help you identify unused entities depending on your platform type. Optimizer for Jira, Configuration Manager for Jira, Doctor Pro for Jira etc... do some research as each has their own features.

John Dunkelberg

One place I haven't seen a good solution to is boards and filters. With issues (and thus projects) and with custom fields at least we can see their usage. I'm not aware of any tooling that will provide information on when and where filters are being used, and if boards are being used. As such these accumulate over time in your database and clogging up searches.

Another area to consider is user departures, and how you handle inactive users. We have a transition checklist that we use that includes handoff of roles, but there is a real blind spot in the number of filters that may exist out there owned by the inactive user.

Mirek

Glad that you mentioned that @John Dunkelberg since this is a big effort to cleanup Boards and Filters. Especially when you want to cleanup Custom Fields as well.. even you think that CF does not have a value .. you remove it and filter (board) stops working since someone used it in the JQL..

Tanya Christensen

Optimizer for Jira can show agile Boards usage data.

Configuration Manager for Jira has an Integrity Checker (or it can be purchased standalone) which can show dashboards and filters that have errors, such as the field or project in the filter no longer exists so the JQL will fail/error.

Mirek

@Tanya Christensen apps are fine but the point is that system itself by default should prevent from deleting something if thing is still in use.. So the example when you delete a CF without any warning even and that is breaking filters / boards is a good example..

Deleting functions should have build in validation checks.

You have such a thing when you want to for example .. deactivate an user (and he is a project lead or component lead.. it would not allow you.. even that is not so big impact.. ) but when someone delete a CF and a the end it would be used it is much bigger damage and hard to revert. So cleaning up CF is the worst things to do ..

Mirek

There should be no need to use third party apps to do the cleanup.. Jira should by default supports cleanup proces, suggest regulary removing unused schemes, CF etc.

The worst thing is to that when you use and app, then you delete it / uninstall and there is still "junk" in the database that this app left..

So many times app was adding a new type of CF and later on it was "invisible" until you migrated or checked directly database..

Also lets assume that someone did not cleanup Jira and suddenly wants to remove 1000 workflows or schemes.. Why it is not possible to do it in bulk? Doing this one by one is a pain.

So at the end unfortunately we have to relay on scripts or third party apps ..

Mirek

Those are all good practices especially reusing objects - thank you @Marco Nowak for sharing. Those are also things that I follow when managing an instance.

Yes, Jira indeed is not a archiving system. There are certain limits that cannot be bypassed if you want to have you application stable. So that is why cleanup is very important.

It is also a matter of security. Keeping data for 15 years is a bigger risk when someone would be compromised than 2-3 years.

Of course every company should have own policies applied .. If someone really need 15 years that is fine - Jira or Confluence would handle that probably.

Mirek

Yes, first time cleanup is always interesting. You started to see how many things are connected and requires attention..

In case of Jira I personally always start with removing projects.. that is "releasing" all objects connected to projects like schemes..

Then removing schemes.. then at the end individual objects..

In case of Confluence things are more interesting.. since it is much harder to determine is content is really useful to keep or not.. maybe author of this documentation already left company.. maybe nobody is actually viewing that specific page in last year.. but there might be a day that someone would really need it..

On the other hand when someone is leaving is very interesting topic..

If this was a active person having many filters, boards that were shared or pages (especially restricted) .. those all objects might be lost and it is hard to determine later what to do with it ...

Welcome!

It looks like you're new here. Sign in or register to get started.