The 'Archive vs. Migrate Dilemma': How Are You Handling Your Legacy Data?

[#1]

As our journey takes shape for a move to Atlassian cloud, a common question is surfacing for every admin: Does all of this data really need to come with us? Whether you are in a highly regulated industry like Finance or Healthcare, or just managing a decade’s worth of "historical baggage," the challenge is the same. You need to keep legacy data accessible for audits, liability, or historical reference, but you don't necessarily want it cluttering your new, high-performance cloud instance.

We are currently in the early stages of researching a potential Data Center (DC) Offline Archival posture. Our goal is to investigate if a cost-effective data retention path could help ensure that audit obligations do not block the journey to cloud. We are looking to understand if a "System of Record" for legacy data would help you:

• Streamline Your Migration: "Cleaning" your production environment by archiving subsets of data that no longer need to be active.

• Maintain a "Frozen in Time" Record: Fulfilling 7–20+ year retention mandates (SEC, FDA, etc.) or internal audit policies without keeping unpatched servers running.

• Preserve Context & Fidelity: Retaining access to complex plugin data that may not transform perfectly to Cloud.

• Address Data Sovereignty: Keeping specific sensitive or regulated data within your own network perimeter.

---

How Your Insights Help Us

We are at the discovery stage; we are looking to partner with you to explore the feasibility of these solutions. By sharing your experience, you can:

• Inform our Research: Your specific use cases—from performance optimization to legal requirements—will directly inform our understanding of the archival landscape

• Access Best Practice Frameworks: Gain insights into how other strategic peers from Finance to Health etc who have successfully navigated identical regulatory or data hurdles.

• Unblock Your Cloud Journey: Work with us to identify if your archival needs can be met with existing tools like Cloud Vault, or if a specialized offline methodology is required to move your migration forward.

• Reduce DIY Risk: Moving data to unofficial repositories (like S3 buckets) might create security and compliance gaps. We want to help you find a path that keeps your data secure and audit-ready.

How are you handling this today?

Are you looking for a formalized way to archive? What is your primary driver—performance, compliance, or cost?

Drop a comment below or DM me—I’d love to connect and learn how we can help simplify your cloud journey!

[Hua Soon SIM _Akeles_]

Hi,

This is an interesting topic that we have a lot of thoughts on. 

We started working on an offline archiving solution for Jira Server since 2017. Today, the app has refined many iterations and still available on Atlassian Marketplace as Issue Archiver & Attachment Housekeeper for Jira. 

The app is a supplement/alternative to Jira DC's native issue archiving.
For those who does not know, you can check out the differences between Jira DC issue archiving and Issue Archiver.

We have worked with quite a number of customers. There are a few reasons for archivals:

• Housekeeping unwanted projects that are no longer required in future
• Freeing up disk space
• Exporting records for safekeeping or circulation

The reasons why people prefers Jira's native issue archiving are

• having the option to restoring the project to access other features
  • an exported backup cannot be fully restored if the custom fields/screens/workflows/plugins are modified (data integrity)
• having a place to host the data
  • a shared drive is not that accessible on the web (convenience)

So I guess most people will be migrating their data to Jira Cloud whenever possible in term of costs/performance.

The reasons why people are using Issue Archiver & Attachment Housekeeper are

• to have point-in-time snapshots to offline circulation
• to have human readable archives for compliance reasons
• to free up disk space by removing useless attachments
• some 3rd party app data cannot be migrated to Cloud

Hope these insights are helpful.

[__ Jimi Wikman]

From what I can tell, many DC customers will simply have their DC instance become read only, which makes it an archive where they control the data.

Many customers I know are not migrating Jira at all, but instead starting fresh on Cloud and just doing CSV imports if there is anything they are still working on. Confluence tends to be migrated after cleaning as well.

I have not heard of any customer so far who has asked for a separate archiving function, but if there are any benefits that keeping a read-only DC installation on-prem can't accommodate, it would be interesting to learn more.