The Decision Framework: Delete, Hide, Merge, or Keep

Before touching any field, run it through this decision tree:

START: Field identified as cleanup candidate
         │
         ▼
    Has data? ──NO──► Safe to DELETE
         │              (but verify dependencies first)
        YES
         │
         ▼
    Data still valuable? ──NO──► DELETE
         │                        (accept data loss)
        YES
         │
         ▼
    Actively used? ──NO──► HIDE from screens
         │                  (preserve data, reduce clutter)
        YES
         │
         ▼
    Duplicate of another field? ──YES──► MERGE data, then DELETE
         │
        NO
         │
         ▼
    KEEP (it's actually needed)

Let’s break down each option:

The Pre-Deletion Checklist

Before deleting ANY field — even one with zero data — verify it’s not referenced elsewhere. A field can be empty but still break things if it’s wired into your configuration.

SELECT sr.id, sr.filtername, sr.authorname, sr.reqcontent
FROM searchrequest sr
WHERE sr.reqcontent ILIKE '%customfield_10XXX%'
   OR sr.reqcontent ILIKE '%Your Field Name%';

SELECT pp.pagename, pc.id, gup.userprefvalue
FROM gadgetuserpreference gup
JOIN portletconfiguration pc ON pc.id = gup.portletconfiguration
JOIN portalpage pp ON pp.id = pc.portalpage
WHERE gup.userprefvalue LIKE '%customfield_10XXX%'
   OR gup.userprefvalue LIKE '%Your Field Name%';

SELECT cf.cfname, fs.name as screen_name, fst.name as tab_name
FROM fieldscreenlayoutitem fsli
JOIN fieldscreentab fst ON fsli.fieldscreentab = fst.id
JOIN fieldscreen fs ON fst.fieldscreen = fs.id
JOIN customfield cf ON fsli.fieldidentifier = 'customfield_' || cf.id::text
WHERE cf.id = 10XXX;

"Your Field Name" IS NOT EMPTY ORDER BY updated DESC

The Quarantine Method

Here’s the safest approach for fields you’re uncertain about — recommended by experienced administrators including Rachel Wright:

Instead of deleting immediately, quarantine the field first.

Merging Duplicate Fields

When you have two fields with the same name and both contain data, you need to consolidate before deleting one.

Using ScriptRunner’s Built-in Script

1. Install ScriptRunner for Jira if not already installed
2. Go to ScriptRunner → Built-in Scripts → Copy Custom Field Values
3. Create a filter for issues to process:
   Copy

   "Source Field Name" IS NOT EMPTY

4. Select source field (the one you’ll delete)
5. Select destination field (the one you’ll keep)
6. Test on a small filter first (e.g., single project)
7. Run on full filter
8. Verify data copied correctly
9. Delete source field

Before Merging

• Export both fields’ data as backup
• Document which projects used which field
• Notify users that field name might behave differently
• Update any filters/dashboards to use the surviving field

What If Something Breaks?

Despite all precautions, something might go wrong. Here’s your recovery playbook:

Maintaining a Clean System

Cleanup isn’t a one-time project. To prevent field bloat from returning:

Governance

• Require justification for new custom fields
• Designate a field owner for each field
• Set review dates — annual audit at minimum
• Document purpose in field descriptions

Process

• Reuse before create — check existing fields first
• Project-specific contexts — avoid global by default
• Sunset criteria — define when fields should be reviewed for removal

Monitoring

• Track field count over time
• Review Instance Optimizer quarterly
• Re-run audit queries every 6 months