Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How do I migrate Server to Cloud - 1.5 million JIRA issues with attachments


I was at a client last year and ran across the following scenario. 

  • 1.5 million JIRA Server issues needed to be migrated with attachments (couldn't talk them out of it).  It was for a single JIRA project
  • JCMA analysis calculated it would take a couple of days to export/import to cloud.  Unacceptable.

I was not a part of the actual migration and was assigned to another client.  I didn't end up finding out how that migration was accomplished.

Question 1:  How would you do about doing such a migration without impacting the project and allowing work to still be in-progress?

Question 2: Is there a way to migrate only certain data based on a created date and then migrate the data in chunks?


Katarzyna Szumilas_Deviniti_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
Apr 12, 2023

Hi @Tom Gross

Actually, it might not answer all the needs of a typical migration use case, but it's possible to synchronize issues from one instance to another using sync 3rd party add-ons from Atlassian Marketplace:
I'm part of the team responsible for Issue Sync - Synchronization for Jira.

Those apps let you connect DC and Cloud instances and copy over the whole issue - its custom fields, comments, and attachments. To divide work into chunks you can use JQL to narrow down a single synchronization scope.
Might that be the kind of solution you are looking for?

Kasia from Deviniti

That was a scenario I was in last year, and am not facing that now.  But I appreciate your insights.  I will read up on that add-on and see how that might help me in the future.


Hi Tom!

Quite the challenge, but very doable.  My 2 cents are these.  Your mileage may vary.

First and foremost, you definitely want to pre-migrate users, groups and attachments prior to the project data migration.  You can also work with your Cloud Migration Manager to request that your target cloud site is hosted on a dedicated RDS (Amazon Relational Database Service)  instance.  It would depend more on the amount of data (attachments) rather than the number of issues.  This would "help" with the time required for migration.

Question 1: How would you do about doing such a migration without impacting the project and allowing work to still be in-progress?

You can migrate while live, you just lose changes.  You might consider planning that "on this date we start making new tickets in a temporary cloud project and hold off on updating existing tickets.  Post-migration, bulk move the tickets from the temporary cloud project to the PROD project and update the existing issues.


Question 2: Is there a way to migrate only certain data based on a created date and then migrate the data in chunks?

As far as the JCMA is concerned, the smallest chunks are projects.  So a phased migration to cloud is one approach which would also help to address the time required for migration.

CSV or JSON migrations allow for more granular migration approaches but require the project and all required elements (screens, workflows, custom fields, etc.) built in advance.

Hope this helps the conversation.


Like # people like this

Am deep in managing cloud migrations at the moment. I wouldn't trust the JCMA estimates, have found them to be questionable on accuracy. We deliberately run migration rehearsals to help establish our own migration cycle time benchmarks, but you'll find that JCMA only notes plan creation date, doesn't give a time-stamp of migration start and completion times, so they need manual observation and recording. Rehearsals will also flush out the sort of issues you're going to encounter in doing an actual migration, which you'll need to factor into your migration playbook. Also make sure that any Apps used have a quality cloud migration pathway and do your own checks on migration outcomes through rehearsal runs. This can be quite time consuming.

The prior post about smallest chunks for JCMA being projects is spot on. Given the issue count, have they thought about moving historical issues into a second project that acts as an archive? We've had to do this previously when hitting performance ceilings for instances where issue counts over 200k started to degrade performance and the impact it has on indexing time. Pre-migration of attachments can help with the migration time if its attachment heavy.

I'd second the suggestion from Paul of running a temporary cloud project and then doing a bulk move of tickets to the intended PRD target.

Like Paul Hecker likes this

Hi Tom,
I would suggest investigating if, previous the cloud migration, it's possible to archive in server the major part of issues, moving them to another project. Or, better, moving the active issues in a new project and migrate it. The server project could be available in read-only mode.
Such amount suggests that the Jira project has not been divided/fragmented correctly.


The migration time can be affected mainly for attachment storage, but we know that the attachments can be migrated separately and, in case of failure,  it's possible to migrate only the attachment delta.
The main problem, in my opinion, could be the necessary manual fixes in the issues, with such amount. And without considering the possible related issues add-ons that could you have in that instance, that can add the migration more complicated

As an example, we have migrated 5Terabytes of attachments in 5 days, and we have started to migrate only the attachments 1 months before; once a week we have migrated the attachment delta.

Like # people like this


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events