Jira Software Cloud edition Airdrop

Migrate from Jira Software Cloud edition to DevRev or use DevRev for support while continuing to use Jira Software for development. You can also install DevRev for Jira app in your Atlassian organization for additional features and a better experience.

For more information, refer to the Jira Airdrop snap-in on the DevRev marketplace.

Supported objects

The following is a list of Jira Software objects and their corresponding DevRev equivalent. Those marked as Sync to DevRev are eligible for import/sync to DevRev from Jira. Those marked as Sync to Jira are eligible to be synced to Jira from DevRev.

Migrate from Jira to DevRev

In this scenario, the intention is to replace Jira with DevRev. Once the migration is complete, the work that was normally done in Jira would continue in DevRev. This can also be used to evaluate DevRev with real data.

To migrate from Jira to DevRev:

1. Perform a project import to migrate over an entire Jira project.
2. (Optionally) Perform a sync from Jira to DevRev to bring over changes made after the initial import. This step can be repeated as needed.

Using Jira for development

In this scenario, the intention is to keep using Jira for development work. DevRev is used to provide support (tickets, customer conversations, issues) and product planning. Development work can continue in Jira but it's synced to DevRev issues. This allows you to search over issues in Jira and link them to customer tickets without leaving DevRev. You can also take advantage of DevRev's Convergence snap-in to automatically update tickets and conversations based on issue updates happening in Jira.

To continue using Jira for development:

DevRev highly recommends creating a new dedicated Jira account when setting up Jira for development or ongoing 2-way sync.

Use a dedicated Jira administrator account to create the Jira connection and set up the import. This prevents any individual Jira user from receiving too many Jira notifications.

1. Perform a project import to migrate over an entire Jira project.
2. Sync from DevRev to Jira to configure the recipe to Jira.
3. Enable the periodic Sync to automatically sync changes to and from the Jira project.
4. (Optionally) mark a DevRev work item for syncing if you want to create issues in DevRev and have them appear in Jira. Otherwise, only previously imported issue changes are synced to and from the Jira project.

Project import

To ease the transition from Jira to DevRev, you can import your Jira projects into DevRev. The project import is a 1-time bulk import of a Jira project into DevRev. Once this import is complete, several options are made available for that project, such as resyncing changes, syncing back to Jira, and bidirectional syncing.

For best results, imports should be done using an administrator account on the external source. This ensures all necessary permissions are available to complete the import successfully.

To import a Jira project, navigate to Settings > Integrations > Airdrops then select *Start Airdrop or *Airdrop. From there, create a new connection to a Jira site or use an existing connection if you already have one. Once the connection is established, select the project you wish to import. At this point you are prompted to configure how to import the Jira project.

Setting up the import recipe

A Jira project import is highly configurable, and the configurations for a specific project import are referred to as the recipe. Here are some guidelines on what to expect:

• What type of work to create in DevRev?
  • You have the option to import Jira issues as DevRev issues (common - default) or DevRev tickets (uncommon).
  • Choose issues if you use the Jira project to track primarily development work.
  • Choose tickets if you use the Jira project to track only customer requests.
  • There is also an option to import Jira epics as DevRev enhancements. This is useful if you use epics to track large features or projects.
• What Jira types to import?
  • Typically, Jira projects contain multiple types: epics, stories, bugs, and tasks are common.
  • You can configure which types to import from Jira.
• How to map Jira fields to DevRev fields?
  • DevRev tries to automatically and sensibly map your Jira fields to corresponding fields in DevRev, but it may prompt you on how you want to map certain fields.

Sync from Jira to DevRev

After a successful import of a Jira project, you have the sync from Jira to DevRev option. This feature airdrops any new issues and any new changes to previously imported issues.

To perform a one-time sync from Jira to DevRev, go to Settings > Integrations > Airdrops, find the previously imported project, and select the ⇆ > → From Jira to DevRev option.

If the Jira project is created as Private, the global Jira administrator can access its settings but can't see the issues or most of the data (which can be checked by logging in and trying to see the issues). To be able to access the issues, set the global Jira administrator as a project administrator for that particular project separately.

This overrides work's fields, even if they were changed in DevRev.

Sync from DevRev to Jira

After a successful import of a Jira project, you have the sync from DevRev to Jira option. This feature writes back any changes made in DevRev to previously imported issues from Jira. Additionally, any new DevRev work marked for sync to this project is created in Jira.

To perform a one-time sync to Jira, go to Settings > Integrations > Airdrops, find the previously imported project, and select the ⇆ > ← From DevRev to Jira option.

This overrides the issue's fields, even if they were changed in Jira.

Mark a DevRev work item for syncing

Marking with UI

Using the Sync from DevRev to Jira feature, it's possible to sync DevRev work items to Jira projects that have been imported to DevRev. In order to sync a DevRev work item to Jira, it must be marked for syncing. Marking a DevRev work item for syncing can be done during the creation of a work item. During work creation, open the dropdown Select Subtype, set it to the Jira project, and type the work item that should be synced. The display format is as follows: {Jira project name} / issues / {type}. For example, if you want to sync to a Bug to a Jira project called Maple, this would show as Maple / issues / Bug.

Marking with API

To mark an item for sync when creating with the API, the actual subtype name should be used. The subtype format is as follows: _jira\_{jira\_site}\_{jira\_project\_name}\_issues.{type}_. For example, if you want to sync to a Bug to a Jira project called Maple that's served through https://devrev.atlassian.net, this would show as _jira\_devrev.atlassian.net\_maple\_issues.bug_.

After a DevRev work item has been marked for syncing, it's created in the specified Jira project the next time the Sync from DevRev to Jira runs. This can be triggered manually or automatically through a periodic sync. Future syncs keep this item updated on both sides after it has been created in Jira.

Historical Airdrops

To view currently running and previous Airdrops from various sources, do the following:

1. Go to Settings > Integrations > Airdrops.
2. Select the import you want to view.
3. Click on the context menu (⋮) and select View Report.

Periodic sync

After successfully importing to DevRev, you have the option to enable a periodic sync. This allows for automatic synchronization with DevRev on a regular basis. By default, the sync occurs once an hour.

To configure periodic sync, follow these steps:

1. Go to Settings > Integrations > Airdrops.
2. Locate the previously imported project.
3. Select the ⇆ > Set Periodic Sync option.

The Enable automations for synced items setting is optional and can be activated during periodic sync configuration. When enabled, newly created or updated items trigger events, which can initiate webhooks, notifications, Snap-ins, and other processes, as if the events originated directly in DevRev.

If this setting is disabled, updates will not trigger any event-driven processes. This behavior applies only to periodic syncs; no events are triggered during a first-time import or manual sync to or from DevRev.

Delete import

This deletes any content created by the import, including users and works.

An import and all the content it creates can be deleted from DevRev. This can be useful when running POCs or to change the recipe used during the import. Once an import has been deleted, all the content it created gets deleted, even if they were modified in DevRev. It's possible to import the project again after its deletion.

To delete an import and all the content it created, go to Settings > Integrations > Airdrops, find the previously imported project, and select ⋮ > Delete Import.

Jira permissions

Required Jira permissions for successfully importing a Jira project

These permissions are required for a successful import:

• Browse projects: The user making the connection needs this permission for the projects they want to sync. It is advisable to check beforehand if they can browse the issues in the project they wish to bring into DevRev.
• Create issues: Jira not only requires this project scoped permission to create issues, but also to extract issue types. This is a must-have permission to successfully map issues to their respective subtypes in DevRev. It is advisable to check beforehand if the user can create issues in the project they wish to import to DevRev.
• read OAuth scope: Similarly, this scope is required for issue type and issue link type extraction.

Recommended permissions and scopes for successfully importing a Jira project

The following permissions and scopes are recommended as they allow for a full import, making the most out of the Airdrop functionality.

Administer Jira global permission is required for:

• Custom field extraction - without extracting custom fields Airdrop is unable to load them into DevRev, which might become problematic especially on reverse syncs if some of these fields are deemed required by Jira on issue creation.
• Incremental user extraction - admin permissions are required to access the Jira audit records, which signal when new users are added to Jira. While Airdrop extracts all users in the initial import, incremental syncs need admin permissions to bring in new users. If this permission is missing, new users are not brought to DevRev. This affects all items that reference this user - for example this user's comments etc.

A combination of administer Jira global permission and manage OAuth scope is required for:

• Workflow and workflow scheme extraction - without extracted workflows, Airdrop is unable to create the custom stages in DevRev, and they do not match 1 to 1. The stages can still be mapped - for example Done in Jira to Completed in DevRev etc.

Recommended permissions for syncing to Jira

The following are self-explanatory and are usually enabled by default: assign issues, edit issues, transition issues, close issues, link issues, resolve issues, add comments, edit own comments, create attachments. Without its respective permission certain actions can fail. For example without the add comments permission, Airdrop is not able to create comments.

Airdrop does not handle all custom field validations. While some common scenarios are taken care of (for example empty issue description, which can be rejected by Jira), Jira has many different validator options and configurations. It is recommended to remove them in Jira wherever possible. Where removal is not possible, recreate these validations in DevRev.

Airdrop Jira scope and limitations

The following is a list of Airdrop Jira scopes and limitations to keep in mind when performing a Jira Airdrop. These are Jira-specific limitations, there are also some generic Airdrop scopes and limitations.

Attachments

• Attachments to comments in Jira are not transferred as attachments to comments in DevRev. They are transferred as attachments to the issues.

Connection

• The Jira cloud user who authorizes the connection to Jira must be a site admin or the organization admin for Airdrop to be able to collect the email addresses of users. Otherwise, Jira users are collected but they are created with generated email addresses. The DevRev admin can merge the DevU accounts manually.

Updates

• If a Jira field is not writable in the creation or edit screen, Airdrop may fail to create or update that issue in Jira with the corresponding change in DevRev.
• If there is no direct transition from the current issue state to the next state in Jira, the state in Jira is not changed.
• Comments originating from DevRev and synced to Jira are not synced back to DevRev if they are edited in Jira.

Sub-tasks

• When creating a Sub-task in DevRev, the creator has to specify a parent issue in the parent field. This issue also has to be of some Jira subtype so it is synced. If the parent is empty, the Sub-task is not created in Jira, and it shows up as failed in the report under Issues column.

Epics -> Enhancements

If you choose to import Jira epics as DevRev enhancements, the following limitations apply:

• When importing Jira epics as DevRev enhancements a special enhancement subtype is created in DevRev. DevRev enhancements with this subtype sync to Jira as epics. Other enhancements do not sync to Jira. Similarly, if you link an issue to the enhancement of the non-synced subtype, those links show up as errored in the reports. If you assign an issue to a non-synced enhancement and perform a reverse sync, the issue is not assigned to any epic in Jira and after updating the issue in Jira and forward syncing the issue in DevRev defaults to the default part.
• Airdrop extracts all links that are related to synced items. These links can link synced items with non-synced items. In this case the link creation is skipped and the report shows these links as skipped.
• In the forward sync, Airdrop creates parent-child links taken from Jira parent fields. So for example, if a subtask has a parent task, a parent-child link is created in DevRev. These types of links are skipped in the Jira loader as there is no parent link in Jira, and they are shown as skipped in reports. This link is only created once per issue.
• Deleting and reimporting sometimes produce dead links in DevRev, which could point to non-existing issues which were deleted in Airdrop settings. These links do not show up in UI, but they could be extracted, and they show up as failed in the reports.
• Changing an epic into an issue after the corresponding enhancement is already created in DevRev results in the enhancement being removed from the sync. All links that point to this enhancement are skipped in the Jira loader and shown as skipped in the reports.
• Support is not provided for making an enhancement as the default part of the import when importing epics as enhancements. The reason for this is the enhancements can’t be linked together with a IsPartOf link. This could result in issues not being imported as their parts might not be resolved.

Custom links

• All link types not imported as a custom link type in the current sync and not belonging to on the following list are skipped in reverse syncs. Allowed stock links: is_dependent_on, is_duplicate_of, is_parent_of, is_related_to.