Migrating between two external LDAP domains with different username formats

Problem

You've setup Fisheye connected to an external LDAP User Directory and now your organization is migrating users to another domain or LDAP directory where the username format is different. You want to migrate to the new directory without losing any data (commits/reviews etc.) associated with users/usernames from your old LDAP. Simply adding the new directory then disabling the original directory will not transfer over those associations.

Example:

DomainA --> UserA --> username: charlieatlassian

DomainB --> UserA (same user in Domain A) --> username: charlie.atlassian

You are planning to discontinue DomainA, so you want to copy/move/migrate UserA (charlieatlassian) in DomainA to UserA in DomainB (charlie.atlassian) without any data loss.

Workaround

It is possible to make the migration without data loss, but using the internal Fisheye user directory as an intermediate step:

1. Start with the Fisheye Internal Directory ordered as below the external directory.

2. Disable the external directory.

3. Create users in the Internal Directory with their username matching the original/old external directory. It may be worthwhile to script this using something like the Fisheye REST API to avoid manually entering these. (See Fisheye/Crucible restAPI)

4. Promote the Internal Directory above the external directory. At this point if you had manually set a password for the Internal Directory users, you should be able to log in as one and verify that associations are still intact.

5. Rename each user to use the username format of the new external directory. As above, it's probably best to script or otherwise automate this step.

6. Add the new directory connector. If you sync at this point, you should not see new users in Fisheye because they will have the same usernames as the users in the Fisheye Internal Directory.

7. Promote the new directory connector above the Internal Directory.

The expected result here should be that users are able to log in with their new usernames, be authenticated against the new directory connector, and retain their existing associations.

One notable difference here is that if also you remove the external directory connectors or otherwise promote the Internal Directory to the top of the list, all the users will still be in there since they are defined internally.

Caveats

• One important limitation here is that Group membership information won't be maintained using this approach. If groups are managed entirely externally, you'll need to make sure before migrating that the correct groups are configured in the new directory.

• Another limitation is that the commit history for users of non-Git repositories will not be preserved. This occurs because commits are tied to usernames rather than email addresses, as is the case with Git. To address this issue, you can link the new username to the old username for the specific repository by utilising theuser mapping functionality.