Jira archiving before migration: keeping the history without keeping everything in the active instance.
Over the years, a Jira instance accumulates completed projects, old issues, attachments and configurations that sometimes have to be kept, but no longer need to stay in the production environment. BleuLemon helps you decide what should stay active, be cleaned up, archived or deleted. With Aquarius, our Jira archiving solution, the useful history stays readable outside the active instance.
Atlassian Platinum Solution Partner · Alongside IT departments since 2008 · Paris and Lyon
Keeping everything in Jira is not necessarily the best decision
Migrate to a simpler instance. Keep what matters. Avoid carrying your historical debt into your new environment.
After several years in service, a Jira Data Center instance accumulates hundreds of projects, millions of issues, legacy workflows, custom fields, attachments and cross-project links.
Some projects remain active. Others closed years ago, but their data must stay accessible for audit, compliance or traceability. Others have no operational value left.
Carrying everything over into the target lengthens the migration, inflates the volumes to test, multiplies the special cases and transfers into the new instance a historical debt that could have been dealt with beforehand.
An oversized instance has three major impacts.
Sized for a volume that nobody looks at any more.
Each migration rehearsal replays the scope concerned. The larger and more heterogeneous it is, the longer the transfer and acceptance-testing work takes.
Between the IT department, the business teams and compliance, brought in project by project.
Migrating everything is migrating too much. A controlled Jira transformation project is not about moving everything. It is about deciding, project by project: what stays active, what needs cleaning up, what should be archived, what should be deleted.
Carry over, clean up, archive or delete: one decision per project.
Before a migration, an instance consolidation or a change of tooling, every Jira project needs to be qualified. The right goal is not to move the whole history, but to decide the right treatment for each scope.
| Decision | Project situation | Processing | What stays accessible |
|---|---|---|---|
| Carry over | Active project, strategic or still in use | Migration to the target instance | The whole project in the target |
| Clean up | Project still useful but clogged with obsolete data | Correction or purge before migration | The lightened project, in the target |
| Archive | Closed project whose history must be kept | Extraction into a self-contained archive | The history, but outside the active instance |
| Delete | No business value, no retention requirement | Deletion in line with your internal policy | Nothing |
This decision is taken with the business teams, the IT department and, where needed, the compliance or legal teams.
The aim is not to archive as much as possible. It is to give each scope the right treatment and to limit the debt carried into the target instance.
Aquarius: keeping the history of Jira outside Jira.
Aquarius is our extraction and archiving solution for Jira data. It lets you select a scope of issues or projects and produce a structured, self-contained archive that can be read without access to the Jira instance.
HTML and Word, so the content can be read directly.
XML and JSON, to keep a usable representation of the data.
Attachments, comments, links, history, custom fields.
The archive is read-only and needs no Jira licence to access its content.
You can therefore lighten the active instance without losing the history you still need.
Three extraction modes cover the usual situations:
| Mode | Processing | Typical use |
|---|---|---|
| Immediate | Synchronous extraction | Small scopes and one-off needs |
| Background | Asynchronous server-side processing | large volumes |
| Scheduled | recurring trigger | Industrialised or periodic archiving |
The aim is to handle a one-off extraction as easily as putting a more regular archiving policy in place.
Aquarius is used in large Jira Data Center environments, notably in banking and insurance. Its target industries: banking, insurance, defence, healthcare, energy, public sector. Our references on this subject remain covered by confidentiality agreements.
Your data stays in your infrastructure.
Extractions respect the permissions in force: a user can only extract the issues they have access to.
Specific permissions also govern the extraction, download, monitoring and deletion functions.
The archives stay in your infrastructure and therefore remain subject to your own security and operating rules. That can matter particularly in environments with strong confidentiality or sovereignty requirements.
Archiving also contributes to reversibility.
Important data should not be readable only through the tool that produced it.
Keeping a self-contained, readable archive also reduces dependence on the platform that produced it.
An archive that can be read outside the tool that produced it is also a guarantee of reversibility.
This takes on particular importance on a path towards the Cloud: the question is not only how to enter a new platform, but also how to keep control of your estate over time.
Aquarius provides the technical foundation for extracting and reading Jira data. It replaces neither an electronic archiving system (SAE), nor an evidential vault, nor a document retention policy, nor an internal legal sign-off. This limit is stated before the project, not after.
Identify your first candidates for archiving in 30 minutes.
Before your migration, your instance consolidation or your Jira instance clean-up, we help you qualify your application estate and decide what should be carried over, cleaned up, archived or deleted.
At the end of this 30-minute assessment, you have the first elements you need to:
The 30-minute assessment is held by video call, with a written summary within 48 hours. Where the volume justifies it, it can open onto the 6 to 10-week “Controlled Data Center Exit” assessment.
The questions we get asked about Jira archiving
A question that finds no answer here is dealt with in a thirty-minute conversation, about your actual context rather than a general case.
Talk to an expertIs it a Jira backup?
No.
A backup is there to restore a platform after a loss or an incident.
Aquarius extracts a selected scope into a self-contained archive, so that the history can be consulted outside the active instance.
So it replaces neither your backup strategy, nor your restore plan, nor your business continuity arrangements.
In what formats can the archive be read?
Content can be read in HTML and Word, with XML and JSON structured formats.
The archive also keeps the attachments, comments, links, histories and fields associated with the extracted scope.
Can you target a subset of projects or issues?
Yes.
The scope is defined from JQL queries or Jira filters. It is therefore possible to target precisely the data to extract, according to your own criteria.
Can large volumes be handled?
Yes.
Aquarius offers, among other things, a background processing mode for large volumes, and a scheduled mode for recurring extractions.
The setup is sized according to the volume and frequency of extractions.
Aquarius is used today by clients with several million tickets.
Can archiving improve Jira performance?
Reducing the volume of an instance can help simplify its operation, but archiving should not be presented as a universal answer to a performance problem.
If the platform is struggling, we start by identifying the causes before deciding whether archiving is part of the answer.
Is Aquarius enough to meet our legal archiving obligations?
No. Aquarius provides a structured, readable extraction of Jira data. It replaces neither an electronic archiving system (SAE), nor an evidential arrangement, nor the retention policy defined by your organisation.
The applicable obligations must be confirmed with your legal and compliance teams.
When should you archive in a migration schedule?
As early as possible in the preparation phase.
The decision has to be taken before the migration scope is frozen, so that archived data is genuinely removed from the volumes to be transferred and tested.
Should a closed project be archived or deleted?
It depends on the value of its history and on your retention obligations.
If it has to remain readable, archiving is the right answer. If it has no value left and no obligation justifies keeping it, deletion may be preferable.
Going further: Cloud migration·Aquarius·Atlassian licensing·Atlassian at BleuLemon