Migrating cross-project boards and filters is now supported in the Jira Cloud Migration Assistant
October 16, 2023 edited
With the latest release, migrating cross-project boards and filters is now available to all customers.
We continue to advance the capabilities and experience of the Cloud Migration Assistants. In the past 6 months, we have released 18 new versions, each one improving upon the last and helping overcome known customer pain points. Most recently, we’ve eliminated several known workarounds to make the tools more seamless, and we'll continue to introduce further improvements that support the native migration of all your product data without exception.
The addition of cross-project boards and filters into the Jira Cloud Migration Assistant represents the elimination of another workaround that relied on experimental features. With this, you'll see less complexity in executing your migration on your planned migration date.We strongly encourage migrators to upgrade to the latest version of the Cloud Migration Assistants to benefit from these enhancements, among others, that make migrating easier.
We’ve prioritized these features and others in part due to feedback from our Solution Partners and you our migrators who upvoted cross-project boards and global filters on our public JIRA tickets. So please continue to share your feedback with our team and keep an eye out in the future for enhancements designed to increase the dependability of the CMAs.
Feel free to leave a comment on the post below if you’d like to share your thoughts and feedback with us.
*If you've already completed several successful test migrations and your planned migration date is imminent, we leave upgrading to your discretion. While we believe that every new version simplifies migrating in some way, we recognize that changing a plan last minute adds additional risk that some of you may not be comfortable taking.
We stumbled into this functionality when we were setting up our production migration on Friday, since we didn't plan for this and had planned to do post-migration work to recreate the project boards we scrambled to do a test migration at the last minute to check this functionality out. Our test into the sandbox environment went by smoothly. Then on Sunday the 15th we went ahead and did a production migration and had 0 issues. We didn't migrated all cross project boards and filters, just the ones associated to the projects that we migrated, but it did save a good chunk of post-migration work time.
As just one example: filters that are owned by inactive or deleted users. Do we still need to check ahead of migration and clean up that data? Or will the JCMA gracefully handle this kind of data 'inconsistency'.
Also recommended were checks for boards owned by inactive/deleted users, boards linked to non-existent filters, filters with invalid JQL, and invalid groups in filter share permissions. Do we still need to use these checks and clean up the data ahead of migration?
Atlassian Team members are employees working across the company in a wide variety of roles.
November 8, 2023 edited
@Krista Stellar my apologies it looks like I didn't get notified about your comment. Our general principle is to let JCMA migrate an entity as is so in this case you would still want to clean up the underlying data by doing some of those pre-checks. That being said I've passed along this feedback to the developers that having a way to fix the data before migrating built into the CMAs.
4 comments