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; } } }

Optimal ways/methods to clean a Jira cloud instance

Yatish Madhav

Hi,

I manage 2 Jira cloud instances and both have integrations and about 3-5 add ons. One was an instance we set up, learnt on, applied standards, etc. from about a year and a half ago, we were then acquired and we migrated part (some projects) of it to the other that I manage as well. That one was around for a longer time, around 3/4 years, but also had a larger uncontrolled admin list and some security loopholes ...

We also have a private 'internal' connect app as well that is used for an internal system and API calls, etc

What I want to do is (manually but preferably automated) clean up, and if consolidation is possible too, all schemes, statuses, custom fields, workflows, screens, automation rules, etc. as far as possible and upkeep it so ...

As a side note and question here too, would this help speed up the instances? What factors contribute to a slow Jira cloud instance?

Thank you

Yatish

Comments

Sergei Gridnevskii

For the side questions. We use premium features a lot, e.g. Advanced Roadmaps and Insight. They work(ed) really slow if there are more than 5000 issues or 1000 objects. So it is a good idea to remove unneeded items completely or at least transition old issues to Close state.

Also an issue page rendering may be slowed down by plugins, especially if there are 5-6 of them. Try to disable plugins on old cloud instance.

Gabriel Einsdorf

> What factors contribute to a slow Jira cloud instance?

I'd love an answer to that one. I have noticed how different the speed is for various Jira cloud instances

Amir Katz (Outseer)

I'm not sure what you mean by 'consolidation'.

It can mean that you merge different schemes (e.g. permission schemes) and assign the same scheme to multiple projects and then delete the unused schemes.

Same for other types of schemes - issue security, notification, screens, issue types, workflows, etc.

Also, any unused custom fields should be deleted.

Any unused scheme/entity that you remove is a net gain.

What I did is to develop a Python program that connects to the cloud via the REST API and finds unused entities. As of now it finds two types:

- unused issue types (=types that do not appear in any company-managed project)

- unused custom fields (=fields not having contexts or screens)

Benjamin Richards

@Amir Katz (Outseer) - sounds awesome! Is this shareable and or re-usable?

Thanks

Ben

Amir Katz (Outseer)

Unfortunately, I cannot share the code, but I can share the algorithms...

I will author a post instead of putting it here.

Amir Katz (Outseer)

Posted first part (issue types): https://community.atlassian.com/t5/Jira-Software-articles/How-to-Find-Unused-Issue-Types-in-Jira-Cloud-Using-REST-API-in/ba-p/1862000#M511

Marc -Devoteam-

Hi @Yatish Madhav

Consolidating is hard and tedious work.

You would first need to know what schemes, screens, workflows and fields are being used where and how.

We use an app for this, this app is call Optimizer. This app is able to provide you lost of information about all. earlier mentioned topics.

Automated removing or consolidating is tricky, as these action trigger responses to be given, e.g. changing a WF scheme on a project, would require you to maybe tell to what status an original status should be changing to.

Also on cleaning items, some of them in the system require them to be in a sequence, eg. you can delete a screen if used in an active screen scheme or a screen scheme that is used in an issue type screen scheme, etc

Automation rules can be used by multiple projects and can also be impacted on removing fields or workflow (scheme) changes on projects

On items related to performance, Custom Fields, Permission schemes, Apps or database connection pool are options.

If you do experience slowness, it might be worth to reach out to Atlassian an let them check you instance on the database pool settings, as you aren't able to change them yourself.

Cheers,

Marc

Jennifer Choban - HeroCoders

What contributes to a slow Jira instance- too many custom fields. For instructions on cleaning up and merging instances, I would refer to Rachel Wright's book.

Lorenzo Phillips

@Yatish Madhav

I had the same issues as an Atlassian admin over many years. I used to use Optimizer as mentioned before but it did not go far enough for my needs, so I wrote my own apps that give me exactly what I need and also allows me to export reports in the event I need to follow up with a specific owner. I've published (2) apps: Instance Auditor (Jira) and Instance Auditor (Confluence).

I hesitated to respond as I'm not sure we're allowed to self-promote here, but as others offered their own solutions, I felt it might be ok to self-advocate. If not, I apologize in advance to the community and its leaders.

At any rate, I'd welcome your feedback as to whether what I've created is useful or not. If not, what features do you think are missing.

Yatish Madhav

Thanks Gabriel. I would assume so too. I wonder what all the factors are that cause that apart from just cleaning up custom fields, unused projects, etc bilndly

Yatish Madhav

Thanks for this @Jennifer Choban - HeroCoders - yeah, a big fan of Rachel! That graph is interesting

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

performance

security