Moving an EPIC with 200+ child cards to a new Jira Project

[Denise Simmons]

Hello!  I have two questions related to my plans to move an EPIC Jira card with 200+ child issue (cards) to a new Jira Project:

• what are any know impacts? I'm planning to move all data with each child card, e.g.,  attachments, comments, work hours, etc. 
• if we plan to purchase Jira Work Management / Service desk, is it best to hold off on this move until we have the updated features? Or does this even matter?

I'm creating a check list to make sure I capture all details prior to moving 200+ cards and if we increase Jira access any impacts with moving cards prior to updates?

Thank you!

[Trudy Claspill]

Hello @Denise Simmons 

Welcome to the Atlassian community!

Are the source and destination projects Company Managed or Team Managed? If either or both are Team Managed then the customizability of such projects can result in data loss when issues are moved.

If the are Company Managed do they share configurations schemes? If they don't, that can result in data loss or a requirement to map fields and/or data values when moving issues.

Do any of the fields in the projects have custom contexts?

Does either project use Automation Rules?

Are the users assigned to project roles in the source project assigned to the same roles in the destination project?

You don't need to wait for the activation of the other products before the move. Those products will have no impact assuming you weren't planning to move the issues to a project type from those products.

[Denise Simmons]

Thank you @Trudy Claspill !  I believe they are Company managed.  

Our current setup is:

• company managed 
• It's one EPIC card with multiple child issues with custom context
• no automation rules
• assignments are child issue to child issue (moving one to another, so yes, user will be assigned to current child cards and then moved over to new child cards in new Project Epic/child cards)

And thank you for validating no impacts with other products activations. 

I appreciate the help!  

[Trudy Claspill]

If custom field contexts have been defined, and the contexts are different between the source and destination projects, that may force a mapping of the source values to values that are available in the destination project.

If both source and destination are Company Managed projects and they do not share schemes (Field Configuration Schemes, Issue Type Schemes, Issue Type Screen Schemes, Workflow Schemes, etc.) then there may be data loss or additional forced mapping of source values to values available in the schemes of the destination project.