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

[Tom Gross]

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_]

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: https://marketplace.atlassian.com/search?query=issue%20sync
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?

Cheers,
Kasia from Deviniti

[Tom Gross]

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.

Thanks!

[Paul Hecker]

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.

Paul

[Brian Hill]

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.

[Matteo Vecchiato]

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.