How to migrate users using project configurator

[Sateesh Chandra]

Hi

we are planning to migrate project configurator to migrate a project from a JIRA to other owned by a different team. The main problem I see is we use Crowd for authentication and the target JIRA uses AD authentication.Both usernames look different. We have 4000+ users (both active and inactive)

Please advise. 

Regards,

Sateesh

[José Marañón [Awnaba Software S.L.]]

Hi Sateesh,

In principle, it is possible to move the users from the source to the target using Project Configurator for JIRA. Please see this link, for details on how users are handled.

However, take into account that Project Configurator will map users from one instance to another by their username. If the same user has a different name in both directories (for example, if you were schandra at the source and sateesh.chandra at the target AD) then the process will not produce logical results. You would have to resolve those name differences first.

Regards,

José

[Sateesh Chandra]

Hi Jose,

Thank you for the inputs.I am planning to enable JIRA Internal directory in the destination JIRA . 

The destination JIRA team is not allowing all the custom fields to me migrated. They want us to map to their existing fields. Only few new fields are allowed.

I did not see a way to map source fields to the target fields during migration process. Please advise.

Regards,

Sateesh

[José Marañón [Awnaba Software S.L.]]

Hi Sateesh,

This page explains how Project Configurator maps objects in the source instance to objects in the target instance. You will notice that custom fields are mapped when they have the same type and name.

In your case, this means that if you have a custom field "S" at the source instance, and you want to have it mapped to a custom field "T" at the target instance, you might find three different situations:

1. S and T have the same type and name. You have nothing to do, the plugin will map S to T as they stand now.
2. S and T have the same type but different names. Then, simply rename S at the source instance to have the same name as T.
3. S and T have different types. In most cases, there will be no logical way to map S to T, as their types represent incompatible things. For example, if S is a multi select c.f. and T is a single select c.f. there is no way to transfer multiple values for S to a single value for T.
4. In the few cases where such a mapping between different types is logically possible, you should create a new c.f. (let us call it S1) at the source instance. S1 must replicate the configuration of S, for example in the number and values of available options, default values, contexts where it is available, screens or field configurations. Then you would have to copy values that issues have for custom field S to values for those same issues for c.f. S1, maybe with the help of some script. All in all, this is quite complex. If you are still interested in this case, tell us and we could discuss ways to simplify this job using Project Configurator.

After arranging the custom field mappings, it would be a good idea to import with the option "Smart custom field contexts" enabled. This will ensure that the new configuration for these custom fields will not have unwanted interactions with projects that previously exist at the target instance.

Kind regards,

José

P.S. If you are happy with the first answer, please accept it.