You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
We are planning a cross-domain Jira Cloud Migration. In our environment, we have 5 IT projects and 20 team members with tasks across multiple projects that need to be migrated to a new domain, preferably with the least amount of effort and maintaining the full scope of tasks.
At our disposal:
1. Possibility of duplicating email addresses with domain changes to register new accounts for team members.
2. Two ready-made domains: the old one with projects and the new empty one.
3. Intent to conduct a quality migration to bring another success story to the community with step-by-step instructions!
We need help:
1. Official migration strategies from Attlasian in the form of links to current documentation.
2. Real success stories
3. Tips on complex topics, for example: “How to clone a person with all the tasks?” or “How to preserve the project structure during migration?”
4. Negative experiences or identifying pitfalls
We're excited to be active members of the Atlassian community and work together to improve the product for future victories!
Welcome to the Community!
Based on your needs, I'd check out these pages:
Everything you've mentioned is entirely possible without duplication or creating an empty instance of Jira - especially as the size is quite small.
Check-out the documentation, and let us know what you think!
we have successfully prepared the migration, but we are interested in the issue of re-migration. What if we repeat the migration with the same settings and projects:
1. Repeated copying (duplication) will occur
2. Changes will be merged
3. An error will occur
The answer is it depends
Some information (with the right setup) could be merged, like config - but I've also seen it be duplicated. If migrating multiple times, I'd consider removing the previous migration's data, and starting again. Testing into a sandbox / non-prod environment is important.
Some more information on duplication avoidance can be found here: https://support.atlassian.com/migration/docs/how-cloud-to-cloud-migration-links-data-between-sites/
Good Day @Stephen Wright _Elabor8_ ,
Thank you very much for your advice, we purchased a premium license and tested the migration in Sandbox! This gave us a serious understanding of many of the details of migration, and also identified a number of problems for which we, unfortunately, did not find a description of the consequences, and most importantly, a solution among the documentation. We've created a support ticket, but you may have better resources to help us resolve the following issues that were presented in the migration report:
1. The Date of First Response custom field is not supported via migration. The value for this issue will not be migrated.
2. The Date of First Response custom field is not supported via migration. The value for this issue will not be migrated.
3. The issue link may not work in the destination site as the project "ProjectName" might not have migrated.
4. The IT Board Board that references multiple projects might not work properly.
5. The Management Board Board that references multiple projects might not work properly.
6. The UserInGroupCondition is not supported via migration. The workflow will still be migrated, however, the condition on Definition of Done transition will be skipped, which may impact the workflow in your destination.
We will be very grateful and thank you again for the good advice about sandbox testing!
A few different errors there; quite a few are specific to your instance and will likely need specific investigation to resolve - Atlassian Support is probably your best option there.
In general though, check out this help page to see what is and is not moved via Cloud-to-Cloud migrations.
If you are migrating Jira Service Management Projects, these are not included in the current tool. There is an EAP for this you could try though, see this article for more information.