What do you check before archiving old Jira projects?

I have seen old Jira projects cause confusion long after the team has stopped using them. Before archiving or cleaning one up, I like to make a small record of what might still matter.

My usual checks are:

1. Is anything still open, recently updated, or linked from an active project?

2. Are dashboards, filters, automations, or Confluence pages still pointing at this project key?

3. Does anyone need exports for reporting or audit history?

4. Are there project-specific fields, components, versions, or workflows that should be documented before the project disappears from day-to-day view?

5. Is there a clear owner who can confirm the project is truly inactive?

Curious how other admins handle this. Do you archive quickly once work stops, or keep a longer read-only period first?

3 comments

Comment

Usually project owner gives me an order to archive the project. We first create a postfunction in workflows that displays a message "You cannot create issues in this project, please use project XXXX". If he confirms the project is not needed by anyone we make changes to permission scheme making it visible to only project owner.

Anyway "Archived" project issues are excluded from searching and that's all. If someone has direct link to issue he can open the issue. Same for project workflows and so on. So no need to do anything else. Issues will not be on boards and a couple of times users may complain about it, but usually this does not happen.

The only other item that we check besides what you have already listed is whether there any contractual requirements concerning the data.

We have a script that archive projects that are not in use for 3 months.

We will be improving this process by adding a human in the loop, where we will reach out to the existing admin or project lead and check if the project can be deleted instead of just archived.

Why deleted?

Archived projects has been a pain when we want to clean the instance, due to the fact that any entity linked to them (CF, Status, etc...) can be removed from the instance, even when it is only related to archived projects.

The other reason is that if we delay the deletion, the owner of the project might not be around anymore, so it is a bit harder to get a green light to delete the project.

Here's my Jira Archive and Maintenance Policy. I have something similar for Confluence. Since we don't have the archive feature in the standard license level, I have a process that essentially changes the project name, category, and access. It also allows for archiving just issues for active projects.