The problem
Due to the fact that JIira allows the existence of multiple custom fields with the same name and type on a single system, it is not always possible to match custom field from a snapshot to fields on a target system. CMJ uses Configuration Manager for Jira (CMJ) uses a custom field's name and type to match the snapshot with the target system and in case there are multiple get a match between fields in a snapshot and a target system. However, since you can have multiple custom fields with the same name and type on a single Jira instance, it isn't always possible to match all fields correctly. In such cases, CMJ relies on the order of the fields to find the proper a match. However Yet, this approach isn't always reliable when there is ambiguity and deploying . Deploying a snapshot in such cases with improperly matched fields is considered to be a potential cause for when fields are not matched correctly can likely lead to data loss.
Solutions
Since version 3.5 CMJ introduces the ability CMJ allows you to resolve custom field conflicts by providing a UI for manually mapping ambiguously matched fields from the snapshot to their possible matches on the current target. This feature will and avoid the aforementioned data loss. It provides you with a UI that lets you manually map your custom fields in cases where multiple fields with the same name and type exist. This feature can also provide pre-matching if the fields also have the same native IDs.
...
If you're using the REST API for deployment and such a case is detected by detected, by default the deployment will be stopped stop and an error message is shown.
...
will pop up. In this case:
If you want to perform the deployment anyway, the error severity can be reduced to a warning with the same message which doesnwon't stop the deployment. This is controlled by the General Settings' For this purpose, you need to enable the "Stop deployment in case of possible data loss" option in CMJ’s General Settings.
The duplicate fields on the source Jira can be temporarily renamed before creating the snapshot. The Likewise, the duplicate fields on the target instance can be temporarily renamed before deploying the snapshot in order deployment to get properly matcheda proper match.