About Project Configurator for Jira Server/Data Center
Project Configurator (PC) is an app for Jira that automates the process of manually copying projects and configurations from one Jira instance to another. It allows users to specify whether to export and import only specific project configurations or complete projects (configuration and data). PC provides full migration support giving users the tools to:
- Move the configuration and/or data of projects between Jira instances
- Visualise what configuration objects will collide or cause errors when moving projects between instance
- Simulate an import to assess potential impact changes
- Merge projects from multiple smaller instances to a larger instance
- Plan and execute the splitting and organising of one massive Jira instance into smaller ones
- Enforce best practice in making changes in a staging instance before copying the changes to production
PC is able to handle not only the project-specific configurations but also global objects such as custom fields, schemes, and workflows that are referenced in the project configuration. Other global objects that are not, strictly speaking, required for a project configuration such as filters, dashboards, and agile boards can also be migrated.
Benefits of creating an extension
Because apps are a large and integral part of most Jira installations, it would be extremely useful if Jira Administrators could enjoy the same benefits that PC offers for built-in objects when they are moving configurations or data that belong to the main apps they use in Jira.
- They might configure an app in a staging environment and then automatically move those changes to production.
- They could have a group of projects which heavily depend on an app in a departmental Jira and then consolidate those projects transparently into a corporate instance of Jira.
- They could find out which projects, workflows, or custom fields are using specific configuration items defined by the app.
All this can be achieved if a PC extension is created to support the app.
For the app vendor
Your current customers, who are using Project Configurator in their Jira instance, will save time and reduce errors and manual work by being able to move your app configurations and data between their Jira instances. If your customers are moving from one Jira instance to another, e.g. moving from Server to Data Center, to reduce the migration effort, they are likely to review which of their installed apps they want to keep or remove. If your app’s data is easily portable, it increases the chance of them retaining and using your app in the new instance.
Co-marketing opportunity - Adaptavist is keen to work with third-party app vendors to discuss any potential co-marketing opportunities that we collaborate on to promote the new extensions to each user base.
For the end user
Jira Administrators are the end users of PC. They want a convenient method of moving configurations and data between different Jira instances that does not require endless hours of error-prone manual work. Because apps are a large and integral part of most Jira installations, it would be extremely useful if Jira Administrators could enjoy the same benefits that PC offers for built-in objects when they are moving configurations or data that belong to the main apps they use in Jira. For example:
They might configure an app in a staging environment and then automatically move those changes to production.
They could have a group of projects which heavily depend on an app in a departmental Jira and then consolidate those projects transparently into a corporate instance of Jira.
They could find out which projects, workflows, or custom fields are using specific configuration items defined by the app.
All this can be achieved if a PC extension is created to support the app. These features are especially appreciated by large organizations with corporate Jira instances (often Data Center). These organizations are very careful in how they manage their IT systems, so they are usually reluctant to experiment with configuration changes directly in production. They would rather test them first in a testing/staging instance. These customers are very often involved in mergers, acquisitions, or simply changes in corporate structure, which trigger consolidations, splits, or redistribution of projects among Jira instances. All these operations ultimately mean moving projects between different instances.
Making your app easy to migrate, both its configuration and data, is certain to make it more attractive to the most valuable customers in the Atlassian ecosystem.
Benefits for the extension developer
Moving configuration and data to a different Jira instance requires solving several practical problems:
- How to express the content and structure of configuration and data in a way that can be transferred, especially relationships between different objects
- How to map IDs and other instance-specific content to their corresponding values in other instances
- How to collect all items that are required by the projects the user wants to move, but not others that are not related
- What to do when the same items exist in the destination instance
- How to sequence changes in the destination to comply with dependencies among objects
- How to handle and report the myriad of possible errors and warnings
The SPI that PC extensions should implement is designed in a declarative way. As an extension developer, you do not need to worry about all those problems; you only have to express the structure of the information your app manages and the simple operations to create, update, or remove each item. Let PC handle the rest of the export and import problems for you.