You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
we currently use Crowd to manage users that come from various directories, both internal crowd directories and external LDAP.
Now we have to move our main active directory to a new active directory, sadly with new usernames.
Would anyone have any suggestion on what's the best way to do such a migration?
Obviously all the content and history in the connected Jira and Confluence instances should be retained. At best our users shouldn't even notice the change, besides the new username.
That sounds very promising, so aliases would allow our users to still use their old usernames and retain all their data. This would be a good workaround for the meantime.
But from my understanding of the documentation this only adds an additional username that can be used for login and does not change any associated data, therefore not really "migrating" data to the new users, correct?
I would much prefer to cleanly move over all the data to the new usernames.
As a possible solution to my own problem I found the following approach:
(probably do some synchronizations between these steps so that Jira and Confluence know of the new users)
Would this actually work and retain all the data?
Yes it did work in the end although it certainly was a hassle.
The synchronizations to Jira and Confluence inbetween these steps are the key to make it work and have to be in a very specific order and it's also better do disable periodic synchronizations in the meantime.
I also have to give a fair warning on this approach!
Only later we have found some users (~2-3 out of 140) where the "user id" (NOT the "user key") was the mail address instead of the generic "JIRAUSER123". I'm not entirely sure how that came to be.
This does create some issues when using various APIs to integrate Jira/Confluence with other applications.
You should definitely test this several times in a test environment and check all the data.
So if i recall correctly (I hope) my final approach was as follows: