End-to-end process for successful migrating/consolidating Jira projects from Server to Cloud?

[Taranjeet Singh]

Hello Community,

I have never used JCMA (Jira Cloud Migration Assistant) to migrate/consolidate Jira projects from Jira Server to Jira Cloud, but I have heard that JCMA has still some issues/drawbacks due to which the migration/consolidation of Jira projects lacks consistency of migrated data, and people are not willing to still use it for the process.

So, I was wondering to create an open place here to discuss experiences of the community members that have faced any such data migration issues/problems/drawbacks and how did they resolve it? The purpose is to learn about these problems and their solutions from each other, so that we all can use JCMA successfully for this in-demand and important use case.

It would also be great if you someone could also share the high level end-to-end process that you have followed to make sure that JCMA migrates/consolidates Jira projects from Jira Server to Jira Cloud, successfully.

So, you are all welcomed to share your JCMA experience here in comments.......

[Jason Wong]

HI @Taranjeet Singh

Thanks for creating this discussion. I'm working with our team to build the Jira Cloud Migration Assistant and super thankful for any feedback that will help us improve the performance and experience.

I do want to call out a few things we've learnt regarding the above concerns about consistency / drawbacks that may result from the way the app handles complicated situations - particularly how it migrates shared configuration and how it deals with merge conflicts.

We have some improvements on the way, however I think yourself and others interested in this topic are probably also interested in what you can do right now, and so while this reply is a bit long, I'd like to provide you with something you can use now to navigate the concerns.

I can say that for merging and consolidation, the Jira Cloud Migration Assistant is definitely a better way to migrate than using the older alternative methods, as outlined in this document. This is mostly because it will be the least disruptive for teams already working in the consolidated instance. 

It is a little complicated - the exception is when you have Jira Service Desk / Management or Advanced Roadmaps. We are currently adding this capability to the Jira Cloud Migration Assistant. If you have these products, then currently the Jira Cloud Migration Assistant cannot carry out the consolidation in the way I'm describing below. However we are working on it and will make that possible as soon as we can.

You can certainly migrate/consolidate Jira Software or Business projects from multiple Jira Server instances into Jira Cloud, but the most important aspect to be aware of is that the app's default behaviour is to play it safe. It will never overwrite or merge data (the exception is the merging of groups, but you will see that as a warning in the app). Merging can lead to security problems, or existing projects in Cloud being changed by the incoming migration, disrupting existing teams.

As you are not able to use the Jira Cloud Migration Assistant to merge objects during the migration process this needs to be done manually after migration. 

Here are a few tips that I think may help.

1. Be sure to understand how shared configuration is migrated and how merge conflicts are handled

The Jira Cloud Migration Assistant has built-in logic to deal with situations where a particular data object's name is already taken in the target site.

Objects are not simply merged on name - we have a object tracking system that knows if the objects coincidentally have the same name, or are actually the same object based on the migration history in the Jira Cloud Migration Assistant.

This history has limitations, for example, the app is not able to know if you want the migration to merge into an existing workflow over in the consolidated target site (as the app has no context / experience with that object).

For more details, see this document: https://confluence.atlassian.com/cloud/how-the-jira-cloud-migration-assistant-links-your-data-993925217.html

To visualise this, I would say the default behaviour is summarised by these diagrams

2. It is important to not change or delete your configuration after the first migration.

An issue that often arises is "configuration drift". This is where shared configuration between server and cloud goes out of sync after your first migration. If there are any subsequent migrations, we then run into configuration that has "drifted" and due to incompatibilities introduced the migrated data, causing it to fail.

We are working to make improvements on this right now in the Jira Cloud Migration Assistant. The changes will enable you to delete objects and then re-migrate them. To follow work on this feature, please head over to - MIG-163 Better handling of deleted objects with Jira Cloud Migration Assistant.

For now, where possible we would recommend not editing any configuration at all in between migrations until you can see the ability to delete a particular type of object shipped on the above MIG-163 ticket.

3. It's important to understand what data is / is not currently supported

The second important document to read is What gets migrated with the Jira Cloud Migration Assistant.

We have had feedback that it can be a bit onerous to figure out whether this applies to your specific data set and so we have recently shipped a new beta feature that will provide a pre-migration report that outlines what data will not be migrated along with any manual workarounds for you to get that data over to Cloud. In other situations, you may have to do some data clean up and so you might have to go back to the source and repair data and then come back to re-try the migration.

There is also a post-migration version of this report to help save you the time doing an audit of what actually was migrated.

I completely take onboard that we need to make all of this a lot more intuitive and easy to comprehend - we're currently researching into this area with usability interviews so we'd love to speak to anyone who is able to share their migration experiences and apply your learnings with your data and journey to cloud and continually improve - just @mention me in comment and we'll setup a time to meet.

Regards,

Jason Wong

Product Manager, Atlassian Cloud Migrations

[Taranjeet Singh]

@Jason Wong @Thanks for sharing this wonderful and useful information on current JCMA usage possibilities, current migration/consolidation issues and their alternatives and/or upcoming solutions. I am looking forward to hearing more about real experiences and feedback from the community about their success or struggle with using JCMA. This would be really interesting for new JCMA users and very useful feedback for your team as well to help them in improving the overall user experience.

[Jutamat _Kate_ Phothisitthisak]

Thank you for sharing, I not have experience to migrate JIRA server/data center
to JIRA Cloud but used to migrate JIRA servers (12 instance)
and JIRA Cloud (3 instances) into JIRA Data Center with CMJ
(https://botronsoft.atlassian.net) 
however before migration / consolidation you need to identify and capture some conflicts,
as above Jason advise, and migration in-house scripting.
However the most challenging is  how can we captures issues,
communication to user since user 
in each instance having difference  business cases,
configuration, integration and plug in installation, ect,
kind of things need to capture and well-plan ,
along with perform Dry-Run / UAT engagement also important.