...
Now that you have finished developing and testing everything in the DEV instance, you want to transfer all changes to PROD. You export the configuration, using Project Configurator, to an XML file, then import it into PROD. Everything goes correctly: a field called Field One of type multi-select is created in PROD, and the description with the script is also transferred to PROD.
Problem
Project Configurator does not analyze and change arbitrary scripts that may be included in field descriptions, workflow extensions, etc. The script shown above is copied to PROD as it was in DEV. But when Field One is created in PROD, it is assigned a new ID by Jira that does not have to be the same as in DEV: 10532. In fact, it would be a very remarkable coincidence if they actually had the same ID.
This means the script in PROD will fail, as it references a custom field "customfield_10532" that does not exist. Even worse, the script might reference a completely different custom field and silently produce wrong results.
Solution A
The best solution to this problem is referencing objects in scripts by name instead of using IDs. See See our How Project Configurator Works for works page for detailed information on the attributes Project Configurator uses to identify items. Those attributes are guaranteed to be preserved when the configuration is transferred to another instance.
Solution B
If solution A is not practical in your case, the other strategy is looking for ways to make the IDs the same in DEV and PROD. You can achieve this if you perform changes following these steps:
...