Closing this ticket annoying since we have on on-premise server and over 1M tickets with no easy or quick way to archive the closed tickets. 

To be fair, this issue was resolved a year ago because it was shipped. However it is only in Data Center not Server, which has annoyed many customers.

This was closed with no comments - no acknowledgment?  This has been open since 2005 - over a decade. It has 298 votes - But Atlassian is going to just come in and close the issue with no comment whatsoever?

Stay classy, Atlassian.

We need this functionality for our Server instance. There are >1.2m issues and background indexing takes more than 1 day! Should we really buy Data Center to have this feature? 

Agreed with James. Yasin and other users who are using Jira Server, this feature is very much needed in Jira Server as well to help us in maintaining more clean and tidy environment, currently we have more than 1 million issue in our instance and our of which more than 60% are closed and we would like to archive issues those are older than 5 years to reduce the pressure on JIRA.

Yassin - we already did vote for it!  I would recommend raising via "feedback for the founders" https://www.atlassian.com/company/contact/contact-ceos

This is totally unfair towards your Jira Server Customers.

How can we vote to make this feature be considered for the server version?

I also need this for server edition as well

I see that the differences between Data Center and Server are listed at
https://confluence.atlassian.com/enterprise/jira-server-and-data-center-feature-comparison-953651628.html
Project archiving is not a feature in Server. I expect that Issue archiving just followed the same product plan at Atlassian.
When I asked about this I was told basically that the idea is that if you have enough issues to need archiving features, then you're probably big enough to consider using Data Center.

When will this be fixed for Server?

I second Roger's comment... Even with the new dashboards, it is difficult to track down what is in a Server release versus Data Center.

Worse yet, the release notes make false claims as well. I've learned to parse this stuff fairly well, but I can't imagine a new customer making heads or tails of it.

Please split Data Center into a new project, so it will once again be obvious what is included with what.

jkurcek Can you please shed some light on why this was abruptly changed to Data Center Only? It doesn't seem logical, and that label was added just a few days ago. This feature is needed for Server, and this ticket erroneously indicates the need is solved. How can we vote for a Server fix?

How come has been "Resolved" if the label shows "affects-server"? Is there a "dark feature" that allows this?

Can somebody explain me why there is Archived Issue counter in Jira system info - Database statistics?

Needed also for server... I voted for this issue for server version.

I couldn´t agree more with you Johan. More and more features are solved in data center only it seems, and no information in the original issue (which was raised towards the SERVER) whether it will be solved in Server or not. To be fair with us customer I think they should split the Jira server and Jira data center issues into two seperate issues, as they did with the cloud issues.

Becuase now they just close the original issues (and solve them in data center), and you have to create new issues again towards the server version... its just ridiculous...

This is ridiculous that this is ONLY in the data center version ....

Will this be available in Jira Server as well soon ???

Hi @Atlassian, 

I downloaded the EAP for Jira 8.1 and didn't find the Archive or Restore feature. Do I need to enable it first?

Thanks in advance for your answer

I'm working on the understanding this is going to be in server... the statement made above (copied below) is signed by Jira Server Product Management....I'm sure they wouldn't do anything so cynical as to only release it to DC customers.

 
Atlassian Update – 25 October 2018
Hi everyone,

Thank you for your votes and thoughts on this issue.

We fully understand that many of you are dependent on this functionality and we are actively working on addressing the need stated in this issues.

Kind regards,

Jira Server Product Management

Really? Data center specific? What technical reason is there for archiving projects/issues to be a feature only available to data center?

Thank you for including this in your next update!!

Jira Server please.

Nice that's it's now in Jira Data Center, but would love to see this in Jira Server also.

FYI there is a short summary of the current options for archiving Jira issues in this article.

It may worth a read.

I don't think that The plugin you suggest https://marketplace.atlassian.com/apps/1215789/project-archiver-for-jira?hosting=server&tab=overview is able to really archive old issue. In other words, it is not able de "remove" old issues and store them in a separate media to empty my hudge database.

Then able to restore them from a media.

No I think, this is only a "manager" to seperate "alive" projects from "dead" project to clear the list of projects. But the issues & projects still remain in the database.

+1 for Jira Server

+1 When for Jira standalone ?

avin.singhal1
Please have a look here: https://jira.atlassian.com/browse/JRASERVER-67368?focusedCommentId=1814013&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1814013

@IIya Zinnoviev

We are using Jira standalone

Any updated on Archiving on Jira Server?

Best Regards

Avin Singhal

Hi everyone,
We are proud to announce that with Jira 7.10 we have shipped Archiving Projects for Jira Data Center. Now Data Center admins can easily archive and restore projects together with their issues.
Here is a dedicated issue for project archiving: JRASERVER-1450

We are aware that the new capability does not address all the use cases described in this suggestion but we believe some of you may find it very helpful.
Meanwhile, per-issue archiving is considered an addition to our longer term roadmap. We will typically review and update this request in about 6 months from now, at which point we’ll consider whether we need to alter its status.

Kind regards,

Ilya Zinoviev
Jira Developer

For those who needs a very simple archival solution, you can check out the
Issue Archiver for Jira which we have developed.

Do note that the archival is 1-way. It is not possible to restore the archives back into a Jira server again.
However, the archival is human read-able and can fulfil audit requirements.

Hi Watchers and Voters, 

The Archiving in Jira survey is now closed. Thankyou to everyone who took the time to provide feedback, we really appreciate it!

Thanks again, 
The JIRA Software Server team

Hello Watchers and Voters,

Thanks for all your feedback and votes so far, we truly appreciate them. We're currently researching customer's expectations of archiving in JIRA, and we'd really appreciate it if you could take the time to fill out our 15 minute survey, and help us work on something great for you, your team and organization in the near future.

http://www.surveygizmo.com/s3/3789740/Archiving-in-JIRA 

Thanks in advance,

The JIRA Software Server team

An alternate workaround we have found as TAMs is to use an issue sync plugin called Exalate. You can "exalate" selected issues from the production instance to an archive instance which will sync/create copies of the issues to the archive instance. You can then "Unexalate" it to remove the one-one link between synced issues and then delete the original issues from the production instance.

Essentially you can sync the issues to an archiving issues and then delete the issues from the instance in use. The advantage of Exalate is that you can sync the issues moved to the archived instance back to the production instance if necessary.

 This by no means replaces the need for archiving of issues but alleviates the pain using a plugin and a few steps. 

Hi Girish, yes, the issues continue to be indexed.

One way to clean up a bit:

1. Make a new project, and move the issues you actually want to it.
2. Hide the old project with a permission scheme
3. After a suitable retention period, delete the old project

This method is a form of controlled data loss, which is the only way I know to actually "clean" anything, but may not be appropriate for you. Good luck!

Hi,

Does hiding a project using a empty permission scheme still continue to index these issues in the search index?

Is there any progress ?we really need this functionality

Almost exactly 2 years ago I suggested that converting your issues to indexable PDF files, inserting those PDF's into some file search facility, then removing the issues from JIRA, could be an option to implement issue archives.

Looks like implementing this feature in JIRA core is still not happening, and you still have to decide which is more important:

1. to reduce the load on your JIRA server (then you have to move the issues "out" from the server),
2. or the ability to restore the issues (then you play with "visibility" of the issues using JIRA permissions).

If the former is the key, then the PDF method is still a viable option. (For instance, archiving old tickets from Service Desk to a search engine is a great example where restorability is unimportant.)

Let me note that in the last 2 years we have been working on the PDF View Plugin to try to cover this problem more efficiently, and to make the plugin less of a workaround and more of a viable solution. Since 5.1.0 the add-on supports exporting up to 50K issues to a single PDF file (see the shot about a 25K issues test doc) and as it preserves all details of a JIRA Issue in a searchable way, this can be a close-to-comprehensive solution for archiving and storing.

You can use my groovy service like example to archive big tasks:
https://jirasupport.wordpress.com/2016/02/01/new-example-of-groovy-service-for-jira-to-archive-big-tasks/

Will the archiving of JIRA Issues be possible? Attachments images and text to another format?

Don't worry. They can't "archive" it because they don't yet have this functionality.

Good point Jonathan, I retract my comment.
I need to find a way to organize our backlog better though.

Ron.Suhodrev,

Perhaps, according to your last reason, Atlassian should "archive" this and other highly voted issues (since "there are not currently any plans to implement this suggestion").

I have another reason for this I didn't see mentioned. (Sorry if I missed it)
I would like to archive issues because these are features we don't want to currently include (changed our mind). I don't want to just mark them as "Done - Won't Do" because I might change my mind again in a year or two. and meanwhile I don't want them cluttering my backlog

Hi Otto,
It is a minor difference to state that the motivation for the product team is "activating more users" but not "selling more licences". @Greg is on point and his closely resembles our situation.

As a long-term supporter and user of Atlassian products (since Jira 3), I also declined to renew our company's support/maintenance for Jira 6.3 last year due to Atlassian's neglect of core expected features such as this one open for 10 years (talk to @Kayleen Ignacio and @David Mayer if you're interested). The Jira "Cloud" releases and new release of "Service Desk", and the new (more expensive) licensing terms - which I'm sure are successful for Atlassian - are not of any benefit to my company.

Atlassian needs a much stronger focus on their existing core systems, existing customers and their highly-voted tickets; not just large enterprises who could afford an Expert consultation, premium Add-ons, or can attend your Summits. And frankly you probably need to get more developers if a request like this can't get the attention it deserves.

Thanks for the feedback greglions. I'm sorry to hear you moved away from JIRA.

I don't quite follow how it's actually about selling more licenses. If that's an inference that we are not providing archiving to sell more product - that assertion would be entirely wrong. I can't think of a single Atlassian product team that is motivated by the potential of more license sales. We care about activating more users and use that as a metric for many product decisions. This ethos has been a large reason for Atlassian's success.

5-6 years is a long time ago, but it if's who I think it is, Edwin is still with us and runs our JIRA Service Desk Product. Since then we've seen the limits for number of issues pushed back and evaporate with some customers having instances in excess of 2M issues.

Regarding the approach you describe, in more recent times, (since I joined) we've investigated an approach similar to what you mentioned. Essentially we spiked sharding of the lucene index. We found that this approach would keep customers audit compliant and reduce clutter, however, sharding did next to nothing for the objective of increasing performance. Given that performance was the number one reason why customers wanted to archive we decided not to proceed with this approach. Instead we invested directly in improving performance and made significant gains with JIRA 6.4 and beyond.

Its actually about selling more licences….

I spoke to Edwin? ( a previous Jira Product Owner from Atlassian ) and one of the senior Jira engineer (don’t recall his name) about scalability issues with Jira some 5-6 years ago. They came to my office and I even gave them a full dump of oneof our jira to analyse why the instance would crash ( corrupt indexes etc ) when over about 250k tickets.

Anyway, I suggested a simple rule engine that moved all closed tickets of x months to a read-only database/and index so they would not be re-indexed continuously. Should a user wish to find an old ticket, they could use a checkbox “Search Archived Tickets” which would look in the archive.  The engineer thought that would work and very easy to implement and solve several other issues they had…. Never happened. But Atlassian did release “Jira Enterprise” soon after… the highlight of which was a t-shirt from memory.

We now use a different tool for enterprise ticketing.

Thanks for the comments everyone. I really do appreciate the feedback and it helps. I'll continue to share our position openly and without bullsh1t.

Re david.turner@mmal.com.au comments, I'm sorry, I think I didn't explain our position clearly enough. I am not suggesting that audit compliance is a low priority. The point I was trying to make was that when we dig into why archiving is a need for customers, there were essentially three needs (in order of priority);

1. make it faster
2. keep me audit compliant
3. and reduce the clutter.
   The highest priority for virtually all customers was performance. Moreover, when asked "If you could have 2 & 3 only, would you be satisfied?" The answer was "No". i.e. performance was the key driver for archiving.

The additional challenge was that when we look at all the things in JIRA that contribute to it's performance, we believe that the provision of an archiving solution would address 2 & 3 but that we could (and did) make a far more significant impact on performance with direct investment in this area. This investment is ongoing.

I should also clarify that when I talk about cost - I'm only talking about it in relative terms. i.e. when we prioritise work we essntially stack rank initiatives based on the ratio of return vs. cost; Return essentially being how many customers' experiences can we improve how often and cost being how many dev days it will take. Initatives that are high return and low cost rise to the top. Like any organisation, we are limited by the number of people we can throw at a problem. Even if you were to live in a hypothetically unconstrained world where you had unconstrained funds you would still need to prioritise to make relative investment decisions - i.e. how big a team do you put on initative A vs. initative B.

michael.parks comment is really interesting in that it appears to contradict feedback I've heard from customers. I'm glad to hear that performance is no longer a highly ranked concern for Michael. Let me add a little more colour that might provide further context... Every year at Atlassian Summit, all PMs try to get a sense for the highest priorities of our customers. It's a great opportunity for us to have in depth conversations with so many of you. The audience at summit tends to over-index to our enterprise customers and it is also those customers that have clearly told us to improve performance (and are usually the ones asking for archiving to help with performance). Among my biggest take aways from this year's summit was that performance was no longer the top of everyone's list. As you might have seen in the keynote, we've made significant strides in performance and it's heartening to get a signal that says it's being felt by customers. I'm not convinced we've satisfied everyone's performance requirements and we have a lot of NPS data that suggests we need to do more here. However, I'm left wondering if there is a significant change in the needs of our customers that might mean when it comes to archiving de-clutter and audit are more important than performance to the majority of customers. I'd be interested to hear more comments from others as to what's important to them regarding archiving.

Both kurtn and michael.parks mentioned a add-ons that provide archiving. Could you please provide links to these, as I am unaware of any for JIRA and it might be helpful to highlight these as work arounds in the description.

Hopefully you can tell from my reply that Atlassian take all input seriously and that I mean it when I say thank you for sharing it with us. We are lucky to have so many customers that are so engaged and passionate.

Thank you,
Otto

Guys, it's not about performance. JIRA performance, as @Otto mentioned, is fine even with truly absurd numbers of tickets.

@David gave a pretty good laundry list of reasons why this is necessary, but I can add one more: User experience. As you add more and more and more tickets, narrowing down exactly what you want in a filter search becomes more and more difficult. The answer to this is not better filters (since JQL is already about as expressive as can be), but to remove some of those tickets from search.

The fact that it requires a third party addon to provide basic functionality that's been wanted for well over a decade, and then being handed the "it costs too much" argument (especially in light of a recent IPO - do addon devs have more resources than the parent company?!) is... disheartening, and slightly insulting to one's intelligence, to say the least.

@Otto I am confused, there are a number of add-ons that offer this functionality, so its easily possible to add this functionality by non Atlassian folks, it should be simple for you at Atlassian. An open ticket with active comments from 2005 should not have to wait 10 years for a "Sorry were not adding this" reply....

@scott @mike

Hi Otto,

I would disagree that Audit compliance can ever be portrayed as a "lower priority" matter.
And how about large numbers of tickets impacting:

• Long running searches.
• Lucene indexing load/duration.
• Database limits
• Filesystem limits (e.g. GBs of attachments).
• Backups.

We could delete tickets and attachments through scripts, but as many have outlined, it is expected that a leading ticketing application should have a supported archiving method which is non-destructive. Is there any supported work-around solution which does not reduce the richness of the application?

It is simply amazing that highly-requested features should still remain idle on the basis of "cost" when Atlassian just raised billions through their share float last week.