Looking for Guidance on Handling “No Longer Needed” Work Item Types

[Kim Galway]

Looking for Guidance on Handling “No Longer Needed” Work Item Types

Good morning everyone, Our team is reviewing how we manage work item types that are no longer needed in our current process. We want to keep our working space clean and focused, but we also need to retain historical data for reference, audits, and reporting.

Right now, we’re considering two possible approaches:

1. Create a separate space/area for all historical work items This would let us archive older items elsewhere so the active space stays clean.

2. Keep everything in the same space but clearly label older items For example, tagging or marking them as “Legacy” or “Historical” so they’re still accessible but visually separated from active work.

Before we move forward, we’d love to hear how other teams have handled this. Is one of these approaches considered best practice, or is there another method you’ve found more effective for maintaining a clean working environment while preserving history?

Thanks in advance for any insights you can share.

Regards

Kim

[Gunjan Kumar]

Hi Kim, 

Most teams avoid deleting or moving historical work item types, as this can impact reporting and audit history. A common best practice is to remove deprecated work item types from the Work/Issue Type Scheme used by active projects so they can no longer be created, while existing items remain intact and searchable.

For representing “No Longer Needed,” consider using a Resolution or workflow status instead of a separate work item type. This preserves historical context and keeps configuration simpler.

If entire projects are no longer operational, project or issue archiving is another Atlassian-recommended option to reduce clutter while retaining access to historical data.

[Kim Galway]

Good afternoon, 

Thank you for your response — I really appreciate you taking the time to respond.

I believe we are on the right track with what both members have communicated.

Thanks again for your guidance.

Best regards,

Kim

[Ugnius Aušra]

Hi @Kim Galway 

Great question — this is something many teams run into as their processes mature.

In most cases, creating a separate space/project just to store historical work items is not considered best practice unless the data truly belongs to a different operational domain. Moving items elsewhere can break reporting continuity, complicate permissions, and fragment historical metrics.

A more common and sustainable approach is:

Keep everything in the same space, but control visibility

Instead of separating spaces, consider:

• Removing the work item type from the active issue type scheme (so it can’t be used going forward)

• Transitioning existing items to a dedicated “Archived” or “Deprecated” status

• Using labels like legacy or historical if additional filtering is helpful

• Updating boards and filters to exclude archived items by default

• Restricting creation permissions if necessary

This keeps:

• Reporting intact

• Audit history preserved

• Data model clean

• Active boards uncluttered

We did same process in our organization.

[Kim Galway]

Hi [Ugnius Aušra,

Thank you for your detailed response — I really appreciate you taking the time to outline the approach and considerations.

This is very helpful. I’ll take this back to the team so we can review and begin working through the recommended steps.

Thanks again for your guidance.

Best regards,

Kim