When you archive a project, what cleanup do you do?

[Chris Thomas]

This is related to my other thread here. To everyone who commented, thank you very much.

I am going through and removing projects that are no longer being used. I was going to start removing all of the schemes (screen, field, workflow) and realized that if the project needed to be restored, it may not work any more. The same goes for custom fields.

So when you guys archive a project, what cleanup do you do?

[dave_drexler · Accepted solution]

Hi @Chris Thomas - I don't clean up. I simply do three things:

• I apply an 'Archived' permission scheme which hides the project from everyone except admins.
• I rename the project to prepend 'Archived - ' to the project name.
• I add the project to an 'Archived' project category.

[Chris Thomas]

Why do you do this over the built in archive function?

[dave_drexler]

Well, I started doing this procedure years ago, before there WAS an archive function, and for me, it makes things easier to track.

[Chris Thomas]

Fair enough, thanks for the reply.

[Aaron Geister]

I had this built out in many instances too with when no archive was available. I even automated this with automations for jira so when issues were to old I auto moved them to a new project that was an archive project with archive permission and read only. It's hard to stop these when you have it built to use a new function. 

Thanks for sharing @dave_drexler 

[Lopes_ Bonnie]

I do exactly what  @dave_drexler  does.  On Jira Server, there is no Archive capability.

[Lorenzo Phillips]

@Chris Thomas

So if you use the built-in archive functionality, you cannot remove any items associated with the archived project because it still exists. What it does it simply remove the project from any dropdown lists and the "view all projects" list. Archived projects are also not searchable. The whole point is to move them out of the way from day-to-day activities/usage.

Some still prefer the old school method or renaming the project using a naming convention (ex. [Archived], "Archived - ", etc.) and applying an appropriate Permission Scheme. This is the preferred method when you want the archived projects to still be accessible and searchable.

If you do an actual cleanup and remove the projects, then it can be a hassle to clean everything up if you have a large enough instance with enough clutter, unused content in it. As an Atlassian Solutions Partner, my team does a lot of cleaning up as well as assessments. So, I wrote apps in the marketplace, Instance Auditor (Jira) - there's one for Confluence as well, that allows us to bulk remove content/schemes. Of course the rules still apply and you cannot remove anything Jira deems as active, but it has saved my team a ton of time when we have to cleanup.

But what you do also depends on which platform you're on. Server does not have an archiving feature. And my apps are cloud-only so will not help if you're on Server/DC. Just select an appropriate option for the platform you're using and you'll be fine. :)

[Kraig]

I also use something similar to Dave's approach, with one additional step of first moving project to a "view only" permissions scheme, to provide a more gradual and phased approach of view only > no view > archive > delete, allowing x weeks/months for each project to sit in each phase.

The archive step was added in when Jira released the built in archived tool, though we still keep the permission scheme change phases of view only > no view to provide more granular steps and assure projects' issues are truly no longer needed / referenced by users unbeknownst to us admins. 

We don't do any cleanup work until projects are fully deleted specifically because of the concern you raised. Schemes are not as detrimental since they can easily be recreated. Custom fields are the real worry, since that can result in some data loss. I'd recommend taking a look at this article that I discovered not too long ago: https://confluence.atlassian.com/jirakb/custom-field-optimizer-and-archived-issues-976773667.html

[Ryan Beller]

I do the same as @dave_drexler and @Aaron Geister . But like @Lorenzo Phillips says, you could have archived projects in a read-only state rather than hidden, or have them go through both phases; it depends on your organization's needs.

The real Archive feature is only available for Premium and Enterprise Jira licensing, so organizations with Standard or free plans have to use the more manual version of "archiving", where you apply a permission scheme and optionally prepend the project name.

[Aaron Geister]

@Ryan Beller Great add. Totally the case as most of us have had to build archiving feature ourselves until recent. 

[Cindy Sobus]

This is a great conversation.  There are some great answers and tips that we can use since we have not archived any projects yet.  However, that is something we will need to start doing soon.

Thanks

[Aaron Geister · Accepted solution]

If, I am archiving I don't do clean up. If I am removing projects then I do a clean up with screens, schemes, fields etc. 

I do yearly audit and ongoing. So in my practice this is always happening. I would say that its an ongoing processes with building and cleaning up after yourself too. 

Archiving is a great way to move things out the way but its not a great way to clean up the backend. I think you have to find the balance here and ask yourself if this is something that is auditable and if not then can we remove it. If it is auditable then probably need to keep it a prolong time for the data. 

Just a little bit of how I do this. Its always good to see what others do and weave that into practice. 

[Leonie C_ Breitmoser]

Hi there,

this is an interesting topic I struggled with myself. Due to Server EOL we have a clean Datacenter Instance for all new projects. So when the Instance went live I thought about "the best way to archive" to keep my instance clean and sleek.

Nic already suggested a similar way, but here's my reasoning and solution.

Pre-conditions:

1. I wanted to use the archive feature, since we expect to get a huge instance and thus I want to get them out of my index. (Good to know: Project data will be ignored in the index, and removed completely once you re-index Jira. This improves performance by removing data that is stored directly in Jira.)

2. I wanted "one" solution for all archived projects. Since I took over the old instance and they didn't have one way to archive but everyone did as they thought is best... yea you know the rest.

3. I wanted a way to keep our JIRA clean and not messed up with many schemes.

4.. Most of our projects won't be reactivated once they got archived, means I usually don't need the complet setup to work later. Additionally, all my project setups are documented, so I can rebuild the initial setup later if needed.

Archiving projects:

To meet all the pre-conditions, I decided to come up with an Archive Setup for all projects.

Means, I made one ARCHIVE Scheme for all needed schemes and made them as general as possible. From time to time I review these schemes and add all new fields,status, roles, etc. Only for the priority scheme I use the default scheme.

Here's my way of preparing a project before i archive it:

1. Issue type scheme → Archived Projects scheme
2. Workflow scheme → Archived Projects scheme
3. Screen scheme → Archived Projects scheme
4. Field scheme → Archived Projects scheme
5. Priority Scheme → Default priority scheme
6. Permission scheme → Archived Projects scheme
7. Notification Scheme → Archived Projects scheme

Then I can archive it and delete all left over schemes from the project, if they aren't used in another project. 

Hope this gave some insight. 

Best,

Leonie

[Chris Thomas]

So it looks like most people leave the schemes and customizations alone after archiving them.

I very much appreciate the input, thanks everyone.

[Nic Brough -Adaptavist-]

Yes, you can't actually delete schemes if a project is using them, archived or not (well, some you can, but you have still migrate to a new scheme if you do it)

When you archive a project, have a think about how you were using it, and why you're archiving it.  The schemes determine how a project works in general, but do you actually need to keep that lying around?  As you won't be updating anything in it, just reporting, do you need the workflow for example?

A common trick I've seen is to have an "archived" set of schemes - a field configuration that does not hide any fields, a simple screen with every system and custom field on it, and a single workflow that has all status you've got in it.  Before archiving, move the project to use these schemes.  Then you can go through the "inactive" sections of all the scheme lists and bin the ones you're not using any more.