.webp)
Governance & compliance
Bringing a 1,000-User Jira Environment Back Under Control
A governance-first cleanup of workflows, screens, filters, and automation that preserved the legacy still doing real work.
01
The challenge
An enterprise software company with roughly 1,000 Jira users had reached the point where nobody could change anything with confidence. Years of decentralized administration had produced hundreds of near-duplicate workflows, cloned screens, thousands of saved filters, and an automation estate that behaved unpredictably.
The environment had grown the way most large Jira environments grow: one reasonable local decision at a time, for years. Each new team received a cloned configuration and adjusted it, leaving workflows that differed by a renamed status, screens carrying fields nobody filled in, and three separate custom fields recording when work was due. Filters numbered in the thousands, many broken or shared with the entire site, silently feeding dashboards whose owners had long since changed roles.
Automation was the sharpest pain: overlapping triggers, rules reacting to edits made by other rules, global rules written for one project's problem, and rules whose creators had left the company. Administrators practiced a policy of add, never remove, because the blast radius of any deletion was unknowable. Change requests stalled, trust in Jira data eroded, and spreadsheet workarounds started to reappear.
02
Our approach
The obvious instruction was to delete the junk. Two things made that dangerous: nobody could say what the junk was, and some of the mess was load-bearing. Legacy automation encoded business logic that predated everyone in the room, and legacy fields fed reporting leadership relied on. So governance came before cleanup. We built a complete configuration inventory, with usage evidence and dependencies for every workflow, screen, field, filter, and automation rule, and interviewed administrators and team leads about how work actually flows.
Every object was then classified into one of four outcomes: retain, consolidate, retire, or redesign. Two rules governed the exercise: nothing was retired without usage evidence, and nothing was retained without a named owner. The design that followed established a governed workflow library with defined variation points, a field catalog with naming standards, automation standards with deliberate scope and accountable owners, and a legacy exception register that let legacy automations and fields with real dependencies stay, deliberately and on the record.
Implementation ran in staged waves, each rehearsed in the Jira Cloud sandbox before production: obsolete projects archived first, projects moved onto governed workflow schemes in groups, duplicate fields merged with values migrated where history mattered, filters retired with notice, and automation removed on a disable, observe, delete pattern.
Zero unowned configuration, not zero legacy.
03
What we built
- A complete configuration inventoryEvery workflow, screen, field, filter, and automation rule mapped with usage evidence and dependencies, plus the retain, consolidate, retire, redesign decision record.
- A governed workflow libraryA small standard set with defined variation points, replacing per-project cloning without forcing identical workflows on teams that genuinely work differently.
- A field catalogNaming standards, context discipline, merged duplicates, and a request path for anything new.
- Automation standardsProject scope by default and global by exception, a naming convention, standardized rule actors, and a named human owner for every active rule.
- A legacy exception registerLegacy automations and fields with active dependencies formally retained: dependency documented, owner assigned, review date set.
- An administration playbook and change intakeStandards built into the request itself, with a quarterly configuration review to catch drift early.
04
The results
What changed once ownership and evidence replaced guesswork.
- Workflows consolidated into a governed libraryCovering every active project, with deliberate variation instead of per-project cloning.
- Every remaining field owned and catalogedA stated purpose, a documented owner, and known screens for each custom field.
- Automation people can rely onOverlapping rules consolidated, redundant executions eliminated, and an accountable person behind every active rule.
- Filters worth trustingBroken, orphaned, and over-shared filters retired or corrected, with sharing standards for everything new.
- Legacy kept on purposeAutomations and fields with genuine dependencies retained under documented exceptions, with owners and review dates.
- Unowned configuration reduced to effectively zeroAdministrators now evaluate a change's blast radius against documented dependencies instead of discovering them.
05
In their words
Cleanup without breaking legacy
Bring your Jira environment back under control
If nobody can say what is safe to change, cleanup is guesswork. We'll help you determine what should be retired, what should be consolidated, and what genuinely deserves to stay, before cleanup decisions become outages.