How to sync custom release fields between two separate Jira instances based on an Epic ID?

[Hari Shankar]

Hi everyone,

I am looking for advice on how to automate data syncing between two completely separate Jira Cloud instances (Instance A: Digital Team, Instance B: Platform Team).

Our Setup & Use Case:

• Instance A (Digital): Contains our main Epics and Stories.
• Instance B (Platform): Platform developers work on dependent stories here.
• To link them, we have a custom field in Instance B where we manually paste/tag the corresponding Instance A Epic ID.

The Goal:
Whenever a Platform team member updates the following custom fields in an Instance B story:

1. Aspired Quarter
2. Planned Release
3. Revised Release Date

I need those exact values to automatically trigger an update and sync over to the corresponding story/Epic in Instance A based on that tagged Epic ID field. Logging into two instances to manually copy dates is causing massive reporting overhead.

What is the best way to achieve this? Can Jira Automation native webhooks handle this cross-instance lookup, or do we absolutely need a third-party syncing tool like Exalate or Backbone? 

Any examples or rulesets would be greatly appreciated!

[Dmytro Rudenko _ Release Management]

Native automation works for your case. Instance B fires "Send web request" with the Epic key + 3 field values in the payload. Instance A has an "Incoming webhook" trigger, reads {{webhookData}}, uses "For JQL" branch to find the Epic, then "Edit issue" to update. Auth via X-Automation-Webhook-Token header. Atlassian has a how-to: search "How to create and link remote Jira Cloud issues using automation" in their docs.

Three things that bite people:

Option list fields ("Aspired Quarter") have different option IDs per instance even if labels match, so test by name first.
No retry if the receiving side is down, the update is just lost.
And no conflict handling, if both sides edit the same field within seconds, last write wins silently.

Exalate / Backbone handle these properly but cost money and add a tool to maintain. For 3 fields one way, native is fine. If you grow to bidirectional or more fields, third party pays off pretty fast.

One thing worth raising before building though, two separate Jira instances for connected delivery is heavy. If it's there because of M&A or compliance, fair enough. If it's just "no one consolidated", the conversation worth having first is what it'd cost to be on one Jira. Sync overhead never goes down over time, it only grows.

[Arkadiusz Wroblewski]

Hello and welcome to the Community @Hari Shankar 

Does your custom field in Instance B store the actual Instance A issue key like ABC-123, or only another internal ID/reference? The implementation is much simpler if it stores the issue key directly.

In general, that should be easily doable with automation and a web request.

Depending on the scale, Exalate or Backbone would be the safer option. If the scale is small, automation should be fine.

Best,

Arkadiusz 🤠