Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • mapping a configuration element to a chosen destination element,

  • renaming any configuration element such as project, workflow, custom field, user, and more,

  • changing a project key, and

  • changing a user email.

Tip

Contexts can be transformed as well from a JSON file. To learn all the context transformation rules, guidelines and use cases, visit the page we specifically created for the purpose.

In the JSON file, you always need to provide the source ID of the configuration element you want to transform. Later, we’ll show you end-to-end what you need to do in order to apply a JSON transformation.

...

With the Customize mapping option, you can change the destination element the server element is mapped to. All you need to do is provide a different ID in the following way, and the migration analysis will create a new mapping:

...

Code Block
languagejson
"transformation": {
           
    "id": "100123"
 
                }

Projects & configuration elements: Rename

...

Code Block
languagejson
"transformation": {
           
    "name": "New configuration element name",

                 }

After the renaming, any existing mapping will be disregarded afterward.

...

Code Block
languagejson
"transformation": {
 
              "key": "PROJDOC"
               
  }

Users: Change user email

...

Code Block
languagejson
"transformation" : {
           
    "name" : "Karlie Davis",
           
    "email" : "karlie@demo.com",
              
   }

Ways of customizing the configuration mapping

...

With the Download mapping button, you’ll get a JSON file listing the configuration elements in the migration scope. This mapping file contains a description of how all these configuration elements will migrate to Jira Cloud. The following JSON snippet illustrates how configuration elements are listed in the file:

Code Block
languagejson
{
    "issueTypeSchemes": [
        {
            "source": {
                "id": "10208",
                "name": "DOM: Scrum Issue Type Scheme",
                "default": false
     
                },
            "destination": {
                "newObject": true
                  }
        }
        }
                  ]]
}

As you can see, each configuration element has a source and destination record. The source record contains all the details of the server element. The destination record holds information about how this element will be migrated. The configuration element can either be created as a new one or be mapped to an existing destination element.

If you want to customize the default mapping of a configuration element, you need to add a transformation record for it like this:

Code Block
languagejson
{
    "issueTypeSchemes": [
        {
            "source": {
                "id": "10208",
                "name": "DOM: Scrum Issue Type Scheme",
                "default": false
        
             },
            "destination": {
                "newObject": true
         
                 },
            "transformation": {
                "id": "10206"
                     }
        }
    ]
   }
                     ]

Then, in the transformation record, you can map the element to a destination element or create it as a new element.

...

You can create your own mapping file without downloading such from the UI. Just follow the guidelines in this section. After creating it, you upload it with the Customize mapping option in the UI, the same way you would do with a downloaded mapping file. The following snippets show how to construct the JSON records of a transformation to a single configuration element:

Code Block
languagejson
{
    "issueTypeSchemes": [
        {
            "source": {
                "id": "10208",
                      },
            "transformation": {
                "id": "100119"
                     }
        },
                              
     }
                    ]]
}

or

Code Block
languagejson
{
    "issueTypeSchemes": [
        {
            "source": {
                "id": "10208",
          
            },
            "transformation": {
                "name": "Destination issue type scheme",
                     }
        }
        }
                    ]]
}

The source record must contain the ID of the server configuration element. Similarly to the example above, you can add more details to the source record. However, for a successful transformation, the only required component for the source record is the source element’s ID. Then, you need to have a transformation with the new ID or name, as shown in the example above. For projects, you can also change their key this way, and for users their email addresses and keys.

...

Users are mapped by their name. So, in the source record, you need to provide the source user’s name:

Code Block
languagejson
{
    "users": [
        {
            "source": {
                "id": "Karlie Davis",
  
                   },
            "transformation" : {
                "email" : "karlie@test.com",
                }
              }
    ]
   }
         ]

You can learn more about what you can do with users in the User Transformations document.

...

We’ve also built a fail-safe mechanism into the analysis process to avoid data loss or migration failures. It’s able to detect and report conflicts that can be introduced with customized mapping, such as:

  • Multiple source configuration elements are mapped to the same destination element after transformations.

  • A configuration element is mapped to a non-existent destination element.

...