The problem
Configuration Manager for Jira (CMJ) uses a custom field's name and type to 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 a match. Yet, this approach isn't always reliable when there is ambiguity. Deploying a snapshot when fields are not matched correctly can likely lead to data loss.
Solutions
CMJ allows you to resolve custom field conflicts 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 have the same native IDs.
If you're using the REST API for deployment and such a case is detected, by default the deployment will stop and an error message 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 won't stop the deployment. 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. Likewise, the duplicate fields on the target instance can be renamed before deployment to get a proper match.