Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,465,080
Community Members
 
Community Events
176
Community Groups

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

Rob Horan Community Leader Jun 07, 2022

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.

3 answers

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 . 

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 . 

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 Community Leader Jun 07, 2022

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.

Like Enrico Skottnik likes this

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 Community Leader Jun 09, 2022

Thanks Paul,

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

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!

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events