You may want to migrate behaviours from one Jira instance to another. Currently, there is no automated way of migrating behaviours, but there are some REST APIs that help with migrating the configuration.

Below we explain the process of migrating Behaviours using the REST API, take care when following these instructions.

  1. Enter this URL into your browser address bar to provide the mapping between behaviours and projects/issue types:

    <JiraBaseURL>/rest/scriptrunner/behaviours/latest/config
    <Behaviours>
        <project pid="10001" configuration="1"/>
        <project pid="10003">
            <issuetype id="10004" configuration="2"/>
            <issuetype id="10000" configuration="2"/>
        </project>
    </Behaviours>

    Each configuration ID above (1,2) is a single behaviour.

  2. Paste the following URL into your browser address bar to return the configuration of a behaviour, where 2 is the ID of one of the behaviours above:

    <JiraBaseURL>/rest/scriptrunner/behaviours/latest/config/2

    The configuration of behaviour 2 is shown:

    <config use-validator-plugin="false" validate-jira-requiredness="false" name="test">
        <field id="customfield_10011" readonly="true"/>
        <field
            id="customfield_10013" validator-method="" validator-class="" validator="server"
            validator-script=" getFieldByName(&quot;TextFieldB&quot;).setFormValue(&quot;Hello World&quot;) "/>
        <field id="customfield_10014" required="true"/>
    </config>

    As you can see, custom fields are identified by their ID (for example, customfield_10011). If you are migrating this to another system, check the XML and manually update any custom field IDs that don’t match the new system. If you are editing a behaviour, make changes directly to this XML in a text editor.

    If your development environment is a copy of your production environment, or you are just editing a behaviour, the IDs should match and do not need changing.
    Project and issue types are also represented by IDs and might need updating before migration.
  3. Once the XML is updated, post it to your production instance, using:

    curl  -X POST -u admin:admin --header "X-Atlassian-Token:no-check" --header "Content-Type:application/xml" -d @b1.xml <jira-base-url>/rest/scriptrunner/behaviours/latest/config/1

    Where b1.xml is the contents of the behaviour configuration, and admin:admin is an admin username and password.

    If a behaviour already exists with this ID, the command above overwrites it.
  4. Once you have recreated any behaviours, you can write the mappings to the production server:

    curl  -X POST -u admin:admin --header "X-Atlassian-Token:no-check" --header "Content-Type:application/xml" -d @bh.xml <jira-base-url>/rest/scriptrunner/behaviours/latest/config

    Where bh.xml contains the mappings retrieved in Step 1.

    This overwrites any mappings already defined. Make sure you test the procedure on a non-production instance first.
    Please check the documentation for curl for the system you are on. We are not able to support you in this procedure.

Have questions? Visit the Atlassian Community to connect, share, and learn with other Atlassian users and experts, including Adaptavist staff.

Ask a question about ScriptRunner for JIRA, Bitbucket Server, or Confluence.

Want to learn more? Check out courses on Adaptavist Learn, an online platform to onboard and train new users for Atlassian solutions.