I know that thee is a doc about it, but it is very buggy and doesn't seem to do the work properly (tested on v3.5.7).
Did anyone tried such a thing on v3.5.x? Did such a thing worked for you?
If yes I would very appriciate it if you reply with your solution.
Yes it can be done. Recently we have complete a couple of these migrations. (Generally an internal Crowd directory has been replaced with an AD connection)
It sounds like to me the steps in brief would be something like
I found for 3.5.x the script above was pretty accurate but I do recall a few minor changes I have had to make. Send me your email I can shoot an update through
I got it, thank you.
I still need to test it, but from first glance I noticed you dropped this statment (it is part od Atlassian doc):
update OS_PROPERTYENTRY a, usermigration u
set a.entity_name = concat('CWD_', u.newusername)
where a.entity_name = concat('CWD_', u.oldusername);
Any reason why?
We have done this in the past but did so following that doc and though far from ideal is the only real solution.
There are only two other options I'm aware of.
One is integrating Crowd and determining if it's "user aliasing" features meet your needs.
The other is to implement a custom authenticator for Confluence which would replace usernames on the fly as you need. However all the Confluence content would still have the original names embedded in all but the first solution - which shouldn't really matter.
are local group memberships preserved when doing this migration? For older versions of Confluence, this has worked for us pretty well, but recent versions seem to discard memberships. Or maybe I'm wrong?
I had to move a user from the "Confluence internal directory" to a "Delegated LDAP Authentication". The user has the same username in both directories, so I did not had to change it.
What I did is: put the "internal directory" down in the list of user directories (, under the "ldap" one. And tadada, the user got migrated. There is very little side effect to the process (in our case) because the user was the only real user in the internal directory.
to cut a very long story short: no, local groups were not preserved. We wrote a couple of ugly scripts and sql queries to work around it and luckily it has been working without any major issues so far.
Hi Community friends, We're working on sourcing more reviews on Capterra – a popular software review site – to help teams like yours make more informed decisions when choosing an inc...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events