Migrate Users and Groups from JIRA or Crowd Directories to a Locally Managed Directory
When to use this KB
This KB outlines the process for migrating groups and their memberships from a JIRA Directory Connector or Crowd Directory Connector to one of the following directories:
In order for the migration to retain the users in the LDAP directory, the user must exist in LDAP with an identical username as they have in JIRA or Crowd. If their username is different, you will need to incorporate the queries from the How do I change a username prior to Confluence 5.3 to make sure they usernames match.This process requires the use of direct database manipulation and is not part of Confluence's intended functionality. As such, this process is not covered under the Atlassian Support Offerings and the information on this page is provided as-is. It should be thoroughly tested in a development or staging environment before implementing any changes in your production instance.
Step 1: Create the second directory
Using the above links, follow the directory setup steps for the directory you wish to migrate your users and groups into. If your directory has existing information from an external source, such as LDAP, that information will be temporarily removed from the directory until Confluence pulls the data back over from LDAP. See the directory descriptions for specific details on sync behaviors.
Step 2: Update the user and group tables
The queries below will perform a swap of all users and groups in either directory. If your target directory has existing local groups, they will be removed. Additionally, for an Internal Directory with LDAP Authentication, some users that were not in JIRA or Crowd may not show up in your user browser until they authenticate into Confluence successfully (per this behavior). Please make a backup of your database before attempting any of these changes.
Queries written in Postgres:
BEGIN;
alter table cwd_user drop constraint cwd_user_name_dir_id;
update cwd_user
set directory_id = (case
when directory_id=OldDirectoryID then NewDirectoryID
when directory_id=NewDirectoryID then OldDirectoryID
else directory_id
end);
alter table cwd_user add constraint cwd_user_name_dir_id unique (lower_user_name, directory_id);
alter table cwd_user_attribute drop constraint cwd_unique_usr_attr;
update cwd_user_attribute
set directory_id = (case
when directory_id=OldDirectoryID then NewDirectoryID
when directory_id=NewDirectoryID then OldDirectoryID
else directory_id
end);
alter table cwd_user_attribute add constraint cwd_unique_usr_attr unique (user_id, directory_id, attribute_name, attribute_lower_value);
alter table cwd_group drop constraint cwd_group_name_dir_id;
update cwd_group
set directory_id = (case
when directory_id=OldDirectoryID then NewDirectoryID
when directory_id=NewDirectoryID then OldDirectoryID
else directory_id
end);
alter table cwd_group add constraint cwd_group_name_dir_id unique (lower_group_name, directory_id);
COMMIT;If you are using a database other than Postgres, the queries may need syntactical changes to execute properly.
If you are migrating the users and groups in the Jira database, you'll need to add the following before the COMMIT.
update cwd_membership
set directory_id = (case
when directory_id=OldDirectoryID then NewDirectoryID
when directory_id=NewDirectoryID then OldDirectoryID
else directory_id
end);Step 3: Perform an LDAP sync and test user logins
After the switch is made, you will need to trigger a sync if you are using the LDAP connector. If you are using the Internal with Delegated Authentication directory, you can skip straight to testing use logins. The group associations for the users should be retained from JIRA or Crowd and now exist as local groups in Confluence such that inherited permissions schemes should still function as they did before decoupling Confluence from the other application.