2. Reasons for creating a PCJ extension

About Project Configurator for Jira Server/Data Center

Project Configurator for Jira (PCJ) 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). PCJ provides full migration support, giving users the tools to:

• Move the configuration and/or data of projects between Jira instances;

• Visualize what configuration objects will collide or cause errors when moving projects between instances;

• Simulate an import to assess potential impact changes;

• Merge projects from multiple smaller instances to a larger instance;

• Plan and execute the splitting and organizing of one massive Jira instance into smaller ones;

• Enforce best practices when making changes in a staging instance before copying the changes to production.

PCJ 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 PCJ 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 that 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 PCJ 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 - Appfire 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 PCJ. They want a convenient method of moving configurations and data between different Jira instances that doesn't 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 PCJ 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 that 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 PCJ 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