<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content


My family likes the adage, "A place for everything and everything in its place..." although the kids may not appreciate it as much as mom and dad. Have any of you parents ever asked your child to clean their room only to discover, upon very careful inspection, that their room is neat and tidy? Until you open the closet door or look under the bed or inspect the dresser and realize what actually happened.  Everything is NOT in its place! That's kind of like archiving a project in Jira (Data Center).  

Don't get me wrong, I absolutely love this feature that was introduced a while ago. But simply archiving a project is like throwing everything in the closet - it tidies things up, but there is still some deep cleaning to do. So what is left? And how do you do it?

For those that use shared configurations (which I recommend because it supports governance and standards), archived projects still retain their configurations. That means the configurations will still appear to be "active" because they are still associated with a project - even if that project is archived. This makes it challenging if you are in the habit of regular, focused maintenance that removes unused configurations (such as issue types, workflows, etc.).

Let's say two active projects, in this example Project A and Project B, use a shared workflow "Standard Development Workflow." Even if you archive Project B, workflow "Standard Development Workflow" will still be associated with Project A and Project B. If you later associate Project A with a different workflow then it will still look like "Standard Development Workflow" is in use because it is still associated with Project B (which is now archived). So you lose an opportunity to dispose of workflow "Standard Development Workflow" because it still appears to be active.

In order to "free up" shared configurations like this one and to be able to identify them as unused and mark them for cleanup, I recommend you establish "archive configuration schemes." These are configurations you would set all archived projects to, so that their previous configurations are no longer marked as actively used. In fact, you might even consider an archiving process to supplement your regular cleanup activities. Here's one option:

  1. Archive a project as part of regular cleanup efforts or upon request.
    1. Don't worry about the configurations at this point... hear me out.
  2. Wait some fixed length of time, such as six months or a year.
    1. The reason for waiting is that, inevitably, people want projects restored for various reasons. Therefore wait a little while to let the dust settle, so to speak.
  3. After the waiting period is over, temporarily restore the archived project.
  4. Apply the "archive configuration schemes" to the restored project:
    1. Issue Type Scheme = Default Issue Type Scheme
      1. This should have all the issue types in it.
    2. Workflow Scheme = Archive Workflow Scheme
      1. The "Archive Workflow Scheme" may be as simple as one status: Done (or some other end-state status).  This "frees up" all other statuses in case you have too many... some of which may need to be cleaned up.
    3. Issue Type Screen Scheme = Default Issue Type Screen Scheme
      1. The "Default Issue Type Screen Scheme" may have a screen scheme that uses one screen with all fields in it.
    4. Field Configuration = Default Field Configuration Scheme or perhaps an Archive Field Configuration Scheme
      1. The Archive Field Configuration Scheme would have all fields as being optional. But the Default Field Configuration Scheme may suffice, especially since the archived project won't be actively used any longer.
    5. Priority Scheme = Default priority scheme
    6. Permission Scheme = Leave the project's existing Permission Scheme as-is (just in case since those permissions were configured that way for a reason)
    7. Issue Security Scheme = Leave the project's existing Issue Security Scheme as-is (same reasoning as the Permission Scheme)
    8. Notification Scheme = Default Notification Scheme
  5. Optionally change the Project category to "Archived projects" (or a similar category)
  6. Re-archive the project.

As you clean up your environment, remember to back up your data before making any big changes. And it's wise to always test your process in a non-production environment before completing it in production.

With these additional housekeeping tips, your archived projects are free of shared configurations (at least the ones that are actively being used). That means more unused configurations can be trashed, which is a good place for them. For parents and Jira administrators alike, we are happiest when there is a place for everything and everything in its place.

New call-to-action

See More From These Topics