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 custom field's name and type to match the snapshot with the target system and in case there are multiple fields with the same name and type, it relies on the order of the fields to find the proper match. However this approach isn't always reliable when there is ambiguity and deploying a snapshot in such cases with improperly matched fields is considered to be a potential cause for data loss.
Solutions
Since version 3.5 CMJ introduces the ability 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 provide pre-matching if the fields also have the same native IDs.
If you're using the REST API for deployment and such case is detected by default the deployment will be stopped and an error message is shown.
You can perform the deployment through the GUI and select the proper matching.
If you want to perform the deployment anyway, the error severity can be reduced to a warning with the same message which doesn't stop the deployment. This is controlled by the General Settings' "Stop deployment in case of possible data loss".
The duplicate fields on the source Jira can be temporarily renamed before creating the snapshot. The duplicate fields on the target instance can be temporarily renamed before deploying the snapshot in order to get properly matched.