How do teams manage storage for older project files and attachments?

[Andy Marco]

Hi everyone,

Just curious how teams here manage older project files, attachments, exports, or backups over time, especially when storage starts building up in Jira or Confluence.

Do you usually archive things locally, move them to cloud storage, or just keep everything inside Atlassian tools?

I’ve been looking at different ways to keep older files organized without cluttering active workspaces. Recently I started exploring different cloud storage options for storing older files and backups, but I wanted to hear what others are actually using in real workflows.

Thanks!

[Philipp Sendek _catworkx_ · Accepted solution]

Hi @Andy Marco and welcome to the community,

I would say this highly depends on the following criteria:

• What kind of data are we talking about?
  • Backups of the application should be stored somewhere outside of the application and then senseful retention policies applied.
  • Attachments of projects or knowledge bases: If they can't be deleted for good, I would find the proper storage within the organization. This could be a newly rented storage, but sometimes even an old local storage might be fine and would be the more price sensitive option.
  • Exports: Same as backups, I would say they lose their value at some point and keeping them might not make any sense beyond the nostalgic factor.
• What value does the data still hold?
  • If the data has any value for the future such as facts that influenced certain decisions, you could simply keep them and consider them important.
  • If not, you could either store them on a cheap storage for the rare case that you need it but don't spend too much on it or you simply delete it.
• Special situation with Rovo and AI: While old and outdated data was a burden simply in terms of storage utilization, it can become a real problem in the age of AI. As not every model can distinguish old and inaccurate data from fresh and accurate data, keeping this data can negatively affect the responses from AI models. So getting rid of it or at least "hiding" it from models is a good idea. This is also one of the key blocker of AI adoption as the models might be great but if they work with bad data, the responses will also be bad.

One last thing on cloud storages: A lot of storage providers have special archive storage that's significantly cheaper than the "normal" storage options. One is Amazon Glacier which is als an AWS storage offering but it's waaay slower than normal storage but super cheap as long as you don't download it - so it's pretty much a data storage insurance policy that you hopefully never have to use. :-)

I hope this helps you making good decisions.

Greetings
Philipp

[Bibek_ikuTeam_]

I completely agreed and vote for the answer.

Thanks @Philipp Sendek _catworkx_ answer covers all the aspects of storage management really well.

For anyone finding this thread in the future, one important lesson is that storage management should be planned in advance, before you ever need a backup, restore, or archive strategy.

A practical approach is to keep attachments outside Jira in platforms like SharePoint, Google Drive, Box, or OneDrive. Otherwise, teams often end up restoring an archived Jira project just to access an old attachment linked to a work item for audits or reference purposes. 

That’s where marketplace apps that integrate external storage with Jira and Confluence can help teams stay organized without bloating active projects. There are solutions available that support multiple storage providers like SharePoint, Google Drive, Box, and OneDrive, making it easier to manage long-term attachments and archives outside Jira itself.

One example is ikuTeam's Cloud Attachment & Workflow Automation for Jira which supports multiple storage solutions, but it’s always worth exploring different alternatives in the Marketplace to see what best fits your organization’s storage, compliance, and audit requirements.

-Bibek