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!

Data portability in JIRA

During last Euro Summit at Barcelona, Keshav Puttaswamy from Atlassian gave a very interesting presentation about the Data Center suite of Atlassian products. The presentation is available in Slideshare if you want to see it.

In the section about JIRA Data Center, Keshav talked about the issue of "data portability", or how to move projects from one instance of JIRA to the other. He identified three use cases:

  • Moving configurations from one instance to another. For example, testing a JIRA workflow in your development or staging environment and then promoting it to production.
  • Moving projects from one instance to another
  • Merging multiple server instances into a single one

He said that Atlassian's first step in addressing this need had been to partner with two Marketplace vendors that have built a large expertise in this area during several years. As you can imagine (wink) Awnaba Software is one of these two selected vendors. The first task of this partnership is to produce documentation ("best practices") that explain how to solve the three use cases.

Actually, the first stage of that documentation is already available in this URL. When preparing this guide (obviously I refer now to the Awnaba version of the guide) we tried to make it clear, easy to follow and oriented to the real job a JIRA admin would have to perform. It contains a comprehensive view of the process of developing and testing changes to the configuration of projects in JIRA and then moving those changes to the production environment with Project Configurator for JIRA.

I am also glad to announce that the other two guides ("Migrating JIRA projects" and "Consolidating JIRA instances") are now being reviewed, so I hope they will be published and available soon.

Happy migrations!

Going to Barcelona!

Very, very soon I will be at Barcelona to join the first Atlassian Euro Summit and AtlasCamp. This is an excellent opportunity to meet users, partners and other vendors, all of them very smart and interesting folks.

If you want to meet and chat for a while, just send an email to our "awnaba" at awnaba dot com account, and we will be delighted to fix an appointment.

See you at Barcelona!

Last week we released version 2.1.3 of Project Configurator for JIRA. This version enables launching export and import of complete projects from the command line. In previous versions it was possible to drive "configuration only" exports and imports from the command line, following the indications in this page, but the same convenience was not available if the user wanted to migrate projects including their issues and attachments. The new version closes this gap. Instructions, shell scripts and examples can be found in this page of the documentation for the add-on. As you will see, using the provided scripts this is a really easy task. Of course, any feedback (comments, questions, etc.) related to those docs will be welcome.

This improvement started as a request at the issue tracker. Thanks Kai !

Versions 2.1.2 of Project Configurator for JIRA were released yesterday. The new release is focused on providing a better user experience when importing complete projects into a different JIRA instance.

At versions 2.1.1 and earlier, when the user launched import of a complete project the plugin extracts components of the zip file and performs some checks on them before sending a response. If the zip file is some hundred MBs in size or larger, this process may take some minutes. The user perception during this time is that the plugin is "frozen", as no response is shown in his browser during that time. Instead, now Project Configurator will launch zip component extraction and first checks as a a background task and return a response immediately. The user will see a progress bar, in a page similar to other stages of the import, so that he gets feedback on the task progress.

Checks in this part of the import about the validity of the zip file, its components, possible collisions with existing data, etc. have been extended and improved so that, in case of trouble, the user will get clearer information on the nature of the problem.

The new version 2.1.1 of Project Configurator for JIRA has just been launched. As usual, it has been released in two different versions: 2.1.1-J6 for JIRA 6.3 and 6.4 and 2.1.1-J7 for JIRA 7.

The version for JIRA 7 is the first one to be officially compatible with the new JIRA 7.3, something that has been demanded by users in the last few days.

The new version is mostly focused in improving error reporting and handling. Some error messages are now clearer and more informative for the JIRA administrator using the tool. In some cases, we have corrected situations where an error was not reported immediately and the import process continued, just to fail some steps later. This made the original error go unreported, complicating a lot the analysis of the problem.

We hope these improvements will make the work of our users easier!

Season's greetings!

To our customers, evaluators and of course to the whole team... Merry Christmas and a happy 2017!

Thanks for being there during 2016. We hope to be together one more year doing wonderful things on JIRA.

In a few days, we plan to release version 2.1.0 of Project Configurator for JIRA. This version will add a new feature to export and import Scrum and Kanban boards as part of the configuration for a group of projects.

This exciting new feature covers all the configurable aspects of these boards. The user will have the option to export all boards, or only those associated to the exported projects. Needless to say, the simulated import feature will show changes that will be applied to existing or new boards before the real import takes place.

Coupled with the feature to export and import complete projects, this will offer a comprehensive solution to move Agile projects across JIRA 7 instances. The project data import for JIRA 7 is able to move sprints and rank data. Join this with the transfer of boards, and Project Configurator becomes an automated tool, able to move an Agile project to another instance of JIRA without leaving any part of it behind.

Hope you will enjoy it!

Hi again, after some months of silence. This did not mean lack of activity, on the contrary, after the release of version 2.0 the support activity has been very intense. In addition, development has produced, apart from a number of bug fixes, interesting improvements. I would like to review some of them here:

  • The data import log has been improved from its original content in version 2.0. This helps the user gather more complete information about the data import process, including any warning or error.
  • It is possible to see the list of optional or mandatory users that could not be created during the data import phase. These users are shown grouped by projects, with the information that was available about them. With this information, the user can assess better the impact of these missing users and take corrective action if appropriate.
  • Locked custom fields are not exported. These are fields created by plugins or applications (for example, JIRA Software or JIRA Service Desk) and their configuration cannot be modified (not even by the JIRA admin...). It does not make any sense to export and import configuration for these custom fields, as this configuration can only be set up by the plugin that owns these custom fields. So, as long as the owner plugin is properly installed in a JIRA instance, those fields are correctly configured and there is not anything we should do about them.
  • And, of course, compatibility with JIRA 7.2...

Please, stay tuned to our blog. Important news coming very soon...

Project Configurator 2.0, both for JIRA 6.X and JIRA 7.X, has been released. Use it and make the most of the time you can save with our add-on when moving projects, merging instances or transferring changes between instances of JIRA.

And if you have suggestions, ideas or opinions (either good or bad, we respect and listen carefully to all of them) please talk to us. File an issue or feature request at our tracker or drop us an email. My account is pepemaranon at awnaba dot com. Your feedback is priceless and it has been the main guide, with difference, in the evolution of Project Configurator since its first day at the Marketplace.


Version 2.0 of our add-on “Project Configurator for JIRA” is due to be released in a few days. This new version is able to export or import a complete project, including its configuration, data and attachments in a single operation.

Another advantages included in this feature are:

  • A selected group of projects can be handled in a single operation.
  • Export will include data and attachments only for exported projects, avoiding the need of a full XML backup.
  • Attachments, if they exist, are automatically included in the process without any additional action by the user.

These possibiilties will further reduce the effort required when moving a group of projects to another instance.

Let us look back in time for a moment. In early 2013, the only way to move a project to another live JIRA instance, was to follow the process outlined in this page. Project Configurator 1.X simplified the job considerably with an automated way of replicating the project configuration in the target instance. We documented this idea in this page of the plugin's "cookbook". Project Configurator 2.0 takes this idea one step further and packages the export and import tasks in a single operation the JIRA admin can launch with a few clicks. So, we hope this will save lots of work and time for many of you.

Of course, Project Configurator 2.0 is still able to export and import only the project configuration. If you need to move configuration changes for some projects from a development environment into a live production instance, this task remains as easy as before.

If the next days, the documentation will be updated with the information relative to this new feature. You are invited to have a look as soon as the new version is released.



Export your project with Project Configurator for JIRA

A good practice to keep clean and optimized our Jira is to have an instance for testing, in this instance we can make any changes or testing without fear of interfering in the performance of our team, after completing the tests we can implement these changes on the production instance with the assurance that we will not include those aspects with undesirable results.

Jira has the functionality to export in XML format (Administration > Export & Import > BackUp System) that is useful for this purpose, then we must import the project using the “Import project” functionality. However, manual mapping may be necessary if our project uses configuration elements that do not exist in the production instance (Issue types, fields, schemes, workflows, statuses, resolutions, users, roles, groups, etc.). In fact when accessing this functionality Jira warns:

“This tool allows you to import a JIRA project from a backup file. Importing a project is a complex operation that requires performing manual to configuring your instance of JIRA changes. These changes require that you have good understanding of, and experience in the administration and configuration of JIRA. ”

It is good practice, but sometimes it can become a tedious routine because you have to take in mind many factors and the possibility of forgetting details in the process.

Awnaba Software help us in this process reducing the time and risk with the “Project Configurator for JIRA” plugin available for JIRA 6 and 7, this plugin allows you to export your project of our test instance in three simple steps, allowing customized configuration elements and then import it into our production instance

The Project Configurator for JIRA plugin, includes the possibility of running a simulated load, where you can have a preview of changes that will be applied to the instance, showing the expected load trace without modifying the database.

Advantages of Project Configurator for JIRA

As administrators of JIRA, we are always looking for the most efficient and effective way to manage our projects. Continuously, we make changes in the configuration of each project, we customize fields, we create workflows, schemes, statuses, users, roles, groups, among other objects. Administrators must be careful about these modifications. Each change must be verified in a test instance before it is launched in the production instance.
The problem appears when transferring each change between test and production instances. The configuration work will have to be repeated, each change must be done one by one on production, becoming a slowly, tedious and error-prone task. An excellent option to solve this problem, is the plugin Project Configurator for JIRA, developed by Awnaba Software S.L. Its main function is to move the configuration of one or several projects from one JIRA instance to another, in a very simple and automated way.

Other advantages of this plugin are:

  • It includes a simulated load feature, that allows for previewing the changes that will be applied.
  • It covers, not only the project specific configuration, but also global objects such as schemes, workflows, statuses, resolutions, users, roles, groups, … that are used by the project.
  • It handles drafts for workflows and workflow schemes and simplifies their activation.
  • The user can choose the group of projects to export.
  • When a configuration is loaded, the plugin will compute and apply the minimum set of changes required to replicate it in the target instance.

This plugin has been very well received by the community, surpassing the 1100 active installations today. It is definitely a very helpful tool that saves a great deal of time and work.

It is available for JIRA Server, both for JIRA 6 and JIRA 7.

AtlasCamp 2016 at Barcelona

I will attend AtlasCamp 2016 next week at Barcelona. I will be there from Monday morning until Wednesday afternoon.

Anyone interested in talking about Project Configurator, suggestions, ideas, opinions,... or just having a drink and a chat? Let's meet at Barcelona!

The last version of Project Configurator (v 1.13-JX), released last week, is focused on draft management for workflows and workflow schemes. From the end user point of view, its most relevant feature is the option to publish those drafts automatically. This feature will publish draft workflows and draft workflow schemes that have been created during the import, unless user input is required to map statuses of existing issues under the new workflow scheme. The decision to publish or require user input is made taking into account which existing statuses are not available in the new workflows, and whether there are actually issues in those statuses. This reduces the need of user intervention to the strict minimum.

When user input is required, the import results page will include warnings with direct links (that open in a new window or tab) to the pages where the user can map statuses and publish the drafts. With this guide, the admin can usually finish the job in very few clicks. More information can be found in our wiki.

The same scheme has been implemented for assigning a new workflow scheme to an existing project: automated issue migration whenever possible or facilitated user input to map statuses. Read the full story here.

In the end, it is all about reducing work for the JIRA admin. Automated draft publishing completely eliminates or reduces substantially another manual task.