Example Use Cases
- Bidirectional synchronization
- Unidirectional synchronization
- Synchronize Jira Server with Jira Cloud
- Synchronize one project with multiple others
- Synchronize a private with a public project
- Synchronize projects behind firewalls
- Synchronize without installing
- Synchronize with changing Jiras
- Migrate Jira projects
- Synchronize with Jira Service Desk
- Analyze and fix errors
- Trigger a resync
- Increase the JIRA logging level
Fix common problems
General problem situations
- 411 - Length required
- All fields have English names although Jira is in a different language
- Authentication with an external Jira fails
- Exception: ServiceLocatorImpl has been shut down
- Sync info panel displays wrong synchronization name, and no link to partner project
- Server is not reachable - how to fix it
- Changes are not being synchronized
- Can't change the synchronization user
- Recently created issue types, fields, etc. are not available when editing configuration
Issue specific problem situations
- Admin or project admin permissions are required
- Bad gateway
- Cannot add or remove watcher
- Cannot create new issue without mapped issue type
- Cannot find transition
- Cannot find transition id
- Cannot perform transition
- Component(s) not valid
- Could not resolve value of Project Key
- Fallback user does not exist
- Field not on the Screen
- Incoming Issue Error
- Incompatible message format
- Invalid JQL Filter
- Invalid license
- Invalid regex syntax
- Issue does not exist
- Issues must be assigned
- JIRA is offline
- Missing attachment permissions
- Missing Issue
- Missing issue type mapping
- Missing message
- Missing parent Issue error
- Missing required fields
- No create version permissions
- No project administration permissions
- Option not valid
- Outgoing Issue error
- Outgoing Send Error
- Priority not valid
- Resolution cannot be chosen
- Security level name is not valid
- Sprint does not exist
- Template error
- The requested board cannot be viewed
- User does not exist
- User not assignable
- Version(s) not valid
- Workflow operation not valid
- General problem situations
- Field mapping reference
- REST API
- Synchronization behavior
- Data Encryption
- Handling Personal Data
- How does Backbone affect server performance?
- Do you plan to synchronize with other systems?
- Does Backbone communicate via an encrypted channel?
- Can I synchronize an instance from behind an enterprise firewall?
- Can I synchronize an instance without installing Backbone?
- Can I have the same issue keys in both projects?
- Add a 'sync issue' button to the view issue screen
- Configure only changes made by one synchronization partner to be synchronized
- Rename the project key
- Stop synchronizations when Backbone is restarted
- Limit the synchronized issues
- Basic Authentication Change Notice
- Username Deprecation Notice
- Synchronization Message Flow
- Clear the sync info panel
- Change integration user to atlassian account
Synchronize projects behind firewalls
This use case describes how you can synchronize Jira issues between firewall protected Jiras. This can be helpful when you want to:
- Synchronize Jira issues with a partner, but both Jiras are protected by firewalls so they can't reach each other via HTTP(S).
- Synchronize Jira issues between two Jiras which are physically disconnected, e.g. due to specific classification levels.
With Backbone's distributed configuration, you can synchronize Jira issues and work around firewall issues. You can choose from two options, depending on how you want to exchange data between the two Jiras:
- File-based. Backbone exports all changes to the file system - these files can then be exchanged as you wish, via network folders or pen drives.
- Email-based. Backbone on Jira A sends all changes via mail to Jira B, and vice versa.
If one Jira can reach the other Jira directly via HTTPS or you can define a firewall exception to allow that, we recommend you do so. This simplifies the configuration of Backbone a lot. You can then choose from the other use cases to proceed, e.g. Bidirectional synchronization.
In this guide, you will configure a synchronization using the distributed configuration approach. This enables the Jiras to exchange issue updates via email or files. This guide assumes the other project already exists.
- Make yourself familiar with the concept of a distributed configuration.
- Create a new master synchronization in Jira A. In this step, you select whether you want to use the mail- or file-based exchange. After the creation you can download a handshake file with all important information to create the slave synchronization.
- Create a new slave synchronization in Jira B. Use the handshake file from step 2 to create it. After this step, the master and slave synchronization status switch to stopped.
- Configure some issue type and field mappings in the master synchronization. After adding the mappings, publish them so the slave receives the configuration update.
- Complete the configuration of the added mappings in the slave synchronization.
Good to know
- Backbone must be installed and licensed on both sides. Read more about licenses.
- The full feature set of Backbone is supported in this use case. However, for each configuration side (master or slave) you can only configure that specific side. The mapping between both sides is done using common identifiers, e.g. a message alias for the field mappings.