The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
As teams complete/close projects how do we go about archiving the boards/issues for future reference if needed (thinking audits etc).
If you have the Premium plan, there is a built-in Archiving feature: https://confluence.atlassian.com/adminjiracloud/archive-a-project-1013843066.html
If you are on Standard, you can use the "old school" way of archiving a feature: creating a permission scheme that limits browsing to just administrators, and switching "archived" projects to that scheme (effectively hiding it to regular users, but keeping it available for later audit purposes, etc.):https://confluence.atlassian.com/jirakb/archiving-a-project-in-jira-server-950287459.html
Thank you very much. We are currently on standard but looking at a premium plan. This is another feature we can add to our list.
Yes, this is the best way to archive on Standard version. I suggest naming the Permission Scheme to something like "Archived Project Permission Scheme" so it is easily referenced if new admins come on board they will understand what it is used for.
When is a good time to archive project? The link above shows that if the project is archived, then it won't be appeared in basic or advanced search results. However, our users sometimes would like to look back at an old issue for reference. How do we go about it?
It looks like the link above is referencing Jira Server version. Are you on the Server or Cloud? If on Cloud, do you have the Premium or Standard Version.
In the past when I archived a Projects, I created a new Permission Scheme called 'Archived Project Permission Scheme', removed everyone from all permission EXCEPT kept the 'Browse Project' permission as was. Then I associated this Scheme to the project. This provided everyone with read-only access to the project and still can query, etc. There are no edits, creating issues, etc.
I am using Jira cloud with premium plan. I was referring to this link below.
Ok. I only Archived when the Project is over a year old since it was closed. I follow the above edit commented on utilizing the Permission Scheme.
Hi @Kathi Paquet @Sylvia Fong --
While the instructions I linked to are for Jira Server (not Cloud), the same concept applies. As Kathi correctly points out (and as the documentation mentions), you have two options:
For your use case, if you still need projects to be searchable, then yes, Read-only would probably work.
I agree with @Darryl Lee here. This is the way to go for archiving your projects online (i.e. still residing in your Jira instance, but read-only or hidden).
Thank you, Darryl and Taranjeet. Making a project "Read-only" is the way we do right now. So I am not going to use the "project archive" feature offered by Atlassian then. Thank you for your confirmation.
@Sylvia Fong - what we do is do a search results export of all tickets from a project to a spreadsheet right before we archive the project. We then post the spreadsheet in Confluence. That will give users live links directly to the individual tickets, which do still work even for archived projects.
That's great to know. Do you find it easier to do what you mention above than keeping the project active? I am trying to understand the pros and cons between the 2.
For us, yes. We have 25 teams that each have several active projects, and if we keep them active just so they can reference them, the list of projects gets unmanageable. There will come a point where we archive the Archive project as well and start a new one; our agreed-on changeover is when the Archive project hits 30,000 tickets.
@Esther Strom Thank you! That is a great suggestion.
Good to know. Thanks Esther.
On my project permission, I only allow the project admins and users of the project to be able to browse the projects that they have access to. I think this helps to reduce the confusion for the team to see a full list of projects when they only have access to a portion of them only.
That's definitely helpful, if it works for you. Our teams are cross-functional, so everyone has access to all projects, with a few exceptions.
Where do you go to monitor if your project hits 30k tickets?
I use the REST API, but we have scripts set up for a lot of things; it wouldn't be worth it just to find the number of tickets in a project.