Custom field sprawl, scheme proliferation, permission drift, and abandoned spaces. How to assess the damage, sequence the fixes, and keep it from happening again.
Nobody sets out to build a messy Jira instance. It happens the way debt happens: one reasonable decision at a time, each defensible on its own, none of them coordinated. Five years later there are 900 custom fields, 40 workflow schemes, and a permission model nobody can explain.
The instinct is to start deleting. Resist it for a week. Deleting a custom field that turns out to feed an executive dashboard is a fast way to lose the mandate for the whole cleanup.
Build an inventory first: every custom field with its fill rate and which screens use it, every workflow and scheme with the projects attached, every permission and notification scheme, every project with its last activity date and named owner, and every Confluence space with its last edit. This inventory is the entire basis of the project. Do it properly.
Custom field sprawl. The most common and most damaging. Fields accumulate because creating one is easy and deleting one feels risky. The cost is not storage, it is performance and usability: every field appears in search indexes, screen configurations, and the field picker that admins have to navigate. Look for duplicates with slightly different names, fields with near-zero fill rates, and fields attached to no active screen.
Scheme proliferation. Workflow, screen, field configuration, and permission schemes multiply when each new project gets its own copy rather than reusing an existing one. The fix is consolidation toward a small set of standard schemes with deliberate exceptions, not a scheme per project.
Permission drift. Permissions granted to individuals rather than roles or groups, project leads who left, and schemes that grant broad access because it was faster than diagnosing the real requirement. This is the area where cleanup has genuine security value, not just tidiness.
Abandoned projects and spaces. Dead weight that dilutes search results and confuses new joiners. Archive rather than delete where history might matter.
Sequence by risk and reversibility. Start with things that are safe and visible: archive dead projects and spaces, remove permissions granted to departed individuals, and consolidate obviously duplicated fields. These build confidence and momentum without endangering anything.
Move next to scheme consolidation, which is higher effort but delivers the real performance and maintainability gains. Save the contested items for last, when you have credibility and a track record of not breaking things.
Most governance frameworks fail because they are written as policy documents and enforced by hope. The ones that work share three traits.
Write down who can create projects, who can create fields and under what test, what the naming conventions are, and what triggers a review. Keep it to two pages. Nobody reads ten.
Schedule a quarterly review that checks the same inventory you built at the start: new fields since last quarter and whether they earned their place, projects with no activity, permissions granted to individuals, and schemes created rather than reused.
An hour a quarter prevents the five-year cleanup. That is the entire argument for governance, and it is a better one than any policy document.
Guides only take you so far. Bring the messy specifics and we will tell you what we would actually do.
.webp)