I need to set up synchronization between two separate JIRA installations using email communication. The first system runs on version 4.2.1 while the second one operates on version 4.3.3.
Each installation has its own set of custom fields that need to be mapped between systems. The main requirement is to keep both JIRA instances synchronized by exchanging issue information and status updates via email triggers.
The workflow I’m trying to achieve:
Scenario 1: When someone creates a new ticket in the first JIRA instance, it should automatically send an email notification. The second JIRA instance should pick up this email and create a corresponding ticket with the relevant details.
Scenario 2: When an existing ticket gets updated in the first instance, an email notification should be sent to the second instance, which should then update the matching ticket accordingly.
Both systems need to maintain data consistency and handle the custom field mapping properly. Has anyone implemented a similar email-based integration between different JIRA versions?
While email synchronization between JIRA versions can be tempting, there are significant drawbacks. Reliability is a key issue; emails can be lost or blocked by spam filters, leading to data mismatches that require manual fixes. In my experience syncing JIRA versions 4.2 and 4.5, we encountered frequent delays and data loss. Additionally, the parsing logic can fail due to changes in JIRA’s email formatting across versions, which complicates configuration management. Bidirectional updates further introduce the risk of infinite loops. Ultimately, we transitioned to a REST API integration with custom plugins, which proved to be much more stable and maintainable than the email approach.
Email sync between Jira versions is a nightmare - trust me. We tried it with 4.2 and 4.4 and gave up after dealing with endless duplicates and missed updates. You’d be better off with scheduled CSV exports/imports instead.
We implemented a similar email synchronization between JIRA versions 4.1 and 4.4 a few years ago. While it definitely works, it requires significant custom development for both parsing the email notifications and mapping the custom fields accurately. We designed a middleware solution that would fetch emails from both installations and then transform the data as necessary before creating or updating tickets in the target JIRA system. The main challenge we faced was ensuring referential integrity, especially when there were multiple updates happening simultaneously. To manage this, we integrated a queuing system to prevent conflicts and ensure the operations were executed in the correct order. Additionally, the custom field mapping quickly became complex, as the field IDs did not align across installations. We ended up creating a mapping table to translate field names and values, which was effective, although it required ongoing maintenance with each system update and the addition of new custom fields. Overall, we handled around 200 tickets per day without significant performance issues.