nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira Migration

gheorghe_Ciorba

Hi Team,
We are currently analyzing the possibility of migrating from our data center to the cloud for Jira Service Management, Jira Software, and Confluence.

As part of this analysis, we are comparing the Standard and Premium cloud packages. I have a few questions regarding the storage and site configuration:

Storage Details:

The Standard package for Jira offers 250 GB of storage, while the Premium package provides unlimited storage.

My question is: What exactly is included in the 250 GB storage allocation? Does this include the Jira installation and Jira home directory currently hosted on our data center? Does it also encompass everything currently stored on our servers, including the database, attachments, and other related data?

Current Setup:

At the moment, we have Jira Software and Jira Service Management hosted on the same server within our data center, and they are accessed from the same site.

Cloud Package Configuration:

From my understanding, the Cloud package for Jira Software and the Cloud package for Jira Service Management each come with 250 GB of storage, and each package includes one site.

My question is:

If we migrate to the cloud, will Jira Software and Jira Service Management be hosted on separate sites, each with its own 250 GB storage allocation? Or will they share a single site with a combined storage limit?

Accepted answers

Hans Polder_7ci2ta

@gheorghe_Ciorba ,

Welcome to the community!

Please refer to this article in the knowledge base: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

See this quote:

Jira and Confluence products all come with their own file storage space. This is the case even if you have more than one instance of the same product. For example, if you have two Confluence instances from two sites, each will have its own storage. This storage is primarily used for attachments.

So, the storage does not take into account any of the database/application size that you currently have in Data Center, and you get separate buckets of 250GB for each separate product that you pay for.

Atlassian will manage anything that is needed to operate your Jira or Confluence at the basic level (so, you don't need to worry about anything regarding databases, servers etc).

All comments

Hans Polder_7ci2ta

@gheorghe_Ciorba ,

Welcome to the community!

Please refer to this article in the knowledge base: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

See this quote:

Atlassian will manage anything that is needed to operate your Jira or Confluence at the basic level (so, you don't need to worry about anything regarding databases, servers etc).

gheorghe_Ciorba

Hi Hans,

Thank you for your assistance. I have a few questions regarding the 250 GB storage allocation in the Jira Cloud Standard package, as well as how backups are handled in the cloud.

Storage Allocation:

Does the 250 GB storage include the Jira installation and Jira home directory currently hosted on our data center?

Does it also encompass everything stored on our servers, such as the database, attachments, and other related data?

Currently, we have 80 GB allocated for the Jira installation and Jira home directory, and an additional 100 GB for backups. We want to confirm if we will fit within the 250 GB storage limit after migration.

Backups in the Cloud:

How are backups handled in the Jira Cloud?

Will backups also be stored within the 250 GB storage limit, or are they managed separately?

Is there a retention policy for backups (e.g., are they deleted after a certain time interval)??

Hans Polder_7ci2ta

Hi,

Does the 250 GB storage include the Jira installation and Jira home directory currently hosted on our data center?

No - it is primarily used for attachments. And possibly manually created backups (https://support.atlassian.com/jira-cloud-administration/docs/export-issues/) - but I can't find something concrete about that. Seeing the size of your current setup, I wouldn't worry about that in any way.

Does it also encompass everything stored on our servers, such as the database, attachments, and other related data?

No, primarily attachments. Anything needed for normal operation of the products in cloud (servers/application/database) is delivered out of the box and does not require space in your storage.

How are backups handled in the Jira Cloud?

There is quite some documentation about this, including the page I shared earlier:

https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

As mentioned on this article, the backups Atlassian makes are NOT for restoring any mistakes you make yourself (like deleting the wrong issues, making wrong configuration changes, etcetera). The backups by Atlassian are only aimed at full-restore of their platform in case it fails on their end. You can create backups yourself using https://support.atlassian.com/jira-cloud-administration/docs/export-issues. Likely these backups do consume your storage capacity though. And, backups like these usually take quite some time. You can invest in paid addons in Cloud that help you manage data and backups in a much more granular way, being able to restore more specific sections of information rather than only the whole site.

Will backups also be stored within the 250 GB storage limit, or are they managed separately?

The Atlassian Application backups (not usable by you, only by Atlassian in case of a big failure on their end) will not take space of your storage. But, I assume manually created site backups will.

gheorghe_Ciorba

thank you , this was verry helpful !!

Kārlis Rozenbergs

It's a great discussion. I just wanted to jump in and say that your concerns about storage are spot on—it's something that gave me a lot of sleepless nights during a similar migration project.

The big challenge we faced was that we were flying blind. We didn't know if our 400 GB of DC attachments was mostly junk or critical data. Trying to figure that out before migrating felt impossible.

Long story short, I got so obsessed with this problem that I ended up building a small Python script to get some clarity. It's a simple, read-only tool that just scans the DC instance and spits out an HTML report showing where all the "dead weight" is hiding (massive files on forgotten projects, etc.). It ended up saving us from an immediate, forced upgrade to Premium.

The Ultimate Guide to Analyzing Jira Attachments (Free Tool)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud