Version 2.2.0 of Project Configurator will help make migrations of both configurations and projects easier and safer by addressing some key challenges we’ve heard from users.

While planning or working on a migration, many users want to know the right way to handle configuration items that exist both at the source and target instances. Actually, there is not a single “right way” to do that. Sometimes the default behavior of Project Configurator (apply the configuration it had at the source) is correct, but in some other situations you would prefer to rename one of the objects so that they become different unrelated items.

Either way, the first step is detecting these coincidences between the configuration in both instances, that might eventually become a conflict during the migration if they are not intended to represent the same thing. In order to detect them, the JIRA admin running the import would review carefully the trace of a simulated import. This posed two problems. First of all, in migrations of medium or high complexity it can become a time consuming and error-prone task. Second, it would detect only those coincidences that imply changes to the existing configuration of the target object. Most often, this is what a conscious JIRA admin would be after, but in some cases even a coincidence without changes might be relevant. For example, if both instances have a status called “On hold” but meaning two completely different things, you would not want after the migration to have issues that are in the same status, but for two very different reasons.

Version 2.2.0 of Project Configurator addresses these concerns with two new features that will help make migrations of both configurations and projects seamless. The first feature is called “Import conflict detection“. If you supply an import file (either XML “config-only” or a zip with complete projects) it will produce a report with all configuration objects in JIRA that will be treated as equivalent to objects represented in the new configuration. So this removes the need to review a simulated import trace to detect the coincidences. All of them are shown in a single report. Even better, the report will also show where those configuration objects are used at the target instance. This facilitates analyzing the impact of the potential conflict and also renaming the coincident object (if this is the chosen option).

The other feature is called the “Used by” report. It shows the dependencies between configuration objects in a JIRA instance, in other words, where they are being used. For example, for what projects has a custom field values in issues? Is a custom field used in any workflow? And a screen? Is this field configuration used for more than one field configuration scheme? The “used by” report provides a compact answer to all these and similar questions. It is also easily navigable, as the user can click on an object that uses another and see where the first one is being used, thus moving up in the chain of dependencies.

We expect this report to be very useful when a JIRA admin wants to reorganize configuration items, for example renaming some of them or making sure that a project does not rely on configuration objects shared with other projects. Or simply when an object is going to be changed and we want to know the impact of that change!