Hello everyone! I am excited to share an update! We are working on a comprehensive solution to better handle entities during a C2C migration to avoid duplication. As a first step, we are launching an Early Access Program that will be open from mid-december. Read more about the EAP here: https://community.atlassian.com/t5/Jira-Cloud-Admins-articles/Early-Access-Program-for-solving-duplication-of-Jira-entities/ba-p/2862936

I was assigned a challenging book review and felt overwhelmed, so I decided to seek help from https://paperwriter.com/book-review-writing-service . I’m so glad I did! The writer was exceptional and quickly grasped the key themes and concepts of the book. They crafted a thoughtful and insightful review that not only met the assignment requirements but also enriched my understanding of the material. The paper was well-structured and delivered well before the deadline, allowing me time to make a few adjustments.

+1

Now, Tony's story is really scary! I have the exact same use case and wanted to restore ONE project and support directed me to this ticket, where the Smart merge is not yet rolled out.....we would fall into same trap if I restore a project from SB. We have plenty of Custom fields.....no way to do this now.

Damn. It means I am left with only exporting and importing issues without their attachments...better than nothing but sub optimal. Atlassian should have had a granular backup and restore solution from start. This exists from vendors but requires very careful permission design as I cannot restore from it as of forgotten assigned permissions before the backup....

A bit frustrating

Hi,
I'm the just used the C2C tool and reported to Support about the long time wasted on trying to clean up the "xxx (migrated)" custom fields, because we were migrating just 1 project from our sandbox site to production site. However, the sandbox site was cloned/copied from production site about 1~2 months ago with 800+ custom fields. Yesterday's migration of such a small and simple project on sandbox with just 39 issue took us such a great effort to clean the custom fields is a total surprise to me because after the migration we have 800+ custom fields added on production site with "(migrated)" suffix in the names. And I cannot just simply just delete them, because a few of them actually used by that migrated project. Those 800+ migrated ones need to be check/compared one at a time before I can delete them.
That's why I propose to have an option in C2C to to thoroughly check if the custom fields are actually used by the projects being migrated. If not, they should be skipped. For a large site like ours, this feature can safe a ton of work and time for admin. Thanks.