Is there a way to speed up the JCMA/CCMA user check?

[Rob Horan]

When limiting the user migration to only those needed for the projects/spaces being migrated, the error check seems to take a VERY long time to run - even when the scope is limited to a single project or space. Is there a way to speed this up?

The problem is in many cases with migrations there are large volumes of irrelevant user accounts that come up as problematic which would very likely be omitted if the scope were limited to only the projects/spaces to be migrated.

Ideally we only want to migrate the users that need to be migrated, and only fix the accounts that need fixing.

[Paul Hecker]

Hi Rob,

I actually ran into a similar problem recently.

In my case, because of the large amount of data associated with users, groups and attachments, we pre-migrated them but the job was taking several hours to complete the user check even though the users and groups were already in the cloud.

Our CMM advised us that we should select "All Users & Groups" so that the migration tool did not parse the users and groups according to the projects, or spaces, selected in the migration job.  In this way the migration tool recognized the users and groups were already migrated more quickly.

So once users and groups are migrated, either separately or as part of a migration job, the user and group check on subsequent jobs "should" go faster.

I hope that helps!

Paul

[Rob Horan]

The problem with that approach in this particular case is there are a LOT of users with no email address, and other user account problems - and these are users that would not be migrated when limiting to only those that are needed.

[Paul Hecker]

Hi Rob,

There are still a few different approaches to address this but the short answer is that the user information, even accounts that do not need to be migrated, would need to be fixed.  Here are a few ideas I've done with migration projects.

If migrating from a non-PROD system:

Performing migration testing, or the migration itself, from a non-PROD system that the PROD data has been replicated to provides some options.

1)

If LDAP sync is enabled, increase the LDAP sync to 4 or 6 hours to allow you to do remediation on the non-PROD system and run migration testing.

2)

Export the cwd_user table from the database to identify accounts without email addresses and run UPDATE commands against the cwd_user table to correct them.  We often run update commands to set the email addresses to "userid>@notarealdomain.net>".  This will not identify the email addresses that have incorrect formats or accounts that are using the same email address but you when you create migration jobs in the JCMA and CCMA those will be identified.

3)

Request the UDC tool from your CMM which would allow you to identify blank email addresses, incorrectly formatted email addresses and accounts that share an email address; however, this is only for Jira and not Confluence.

4)

Normally it's recommended that you preserve user accounts of users that are no longer working in the Jira tools or have left the company for historical purposes.  This is so that content they may have developed or modified preserves the user information.  However,  depending on your need, you could remove the user accounts that do not need to migrate but the company would need to understand that any content associated with the deleted users will have the "deleted user" reference on them.

If migrating from a PROD system:

If migrating from a PROD system the same approaches work but it might be better to coordinate remediation with the LDAP Admin so as not to impact operatinations.

To the best of my knowledge there is no easy fix for user related issues but the best approach is to correct the issues in LDAP so that they are no longer an issue.

Good luck!

Regards,

Paul

[Rob Horan]

Thanks Paul,

Its the correcting issues in LDAP part that is especially difficult, especially when dealing with duplicates.

[Paul Hecker]

Understood.  To be frank, once of my migrations the LDAP was never cleared but fortunately I was working from a test instance so I used the extended LDAP sync & cwd_user update method prior to each migration job.

Again, Good luck!

[Deleted user]

We can follow this approach :

1. Perform the user and group check on working day as production migration usually takes place in non-working days. 

2. On day of production migration, since you have already resolved the issues faced in step1 like duplicate/invalid user etc, you can skip the pre migration check by enabling the dark feature as in https://confluence.atlassian.com/jirakb/enable-dark-feature-in-jira-959286331.html , use dark feature com.atlassian.jira.migration.skip.users.preflightcheck . 

[Samyak Masulkar]

Hi @Rob Horan , 

We can follow this approach :

1. Perform the user and group check on working day as production migration usually takes place in non-working days. 

2. On day of production migration, since you have already resolved the issues faced in step1 like duplicate/invalid user etc, you can skip the pre migration check by enabling the dark feature as in https://confluence.atlassian.com/jirakb/enable-dark-feature-in-jira-959286331.html , use dark feature com.atlassian.jira.migration.skip.users.preflightcheck .