How to Sync Two Jira Service Management Instances Without Merging Them

[#1]

Most teams assume syncing two Jira Service Management instances works the same way as a standard Jira-to-Jira sync. It doesn't. And that assumption is where most implementations fall apart before they even start.

I'm Francis Martens, CEO at Exalate. We build integration infrastructure for teams that need to sync work across systems without losing data fidelity or operational control. This is one of the questions we get most from Atlassian admins, so I want to address it directly.

Why can't I just use a normal Jira-to-Jira sync?

Jira Software and Jira Service Management run on different objects. Software is built around sprints, story points, boards, and releases. Service Management is built around request types, SLA clocks, approval states, queues, organizations, and customer portals.

A generic sync only understands the Software-side objects. Point it at two JSM instances, and here's what breaks:

• Request types  don't map to Jira Software issue types, so they land as blank or default values on the other side.
• Organizations  are a JSM-only concept. Customer context disappears entirely.
• Portal visibility,  the distinction between public and agent-only comments, is ignored completely.
• SLA events  fire on JSM workflow transitions, not standard Jira ones. Your SLA clock starts at the wrong moment, or never starts.
• Approval state  doesn't carry across because JSM approvals aren't standard workflow steps.
• Internal comments  are the dangerous ones. JSM flags them separately from public comments. A generic sync doesn't read that flag, which means internal agent notes can land as public comments on your customer's portal. Nobody notices until a customer does.

When do you actually need JSM-to-JSM sync?

Four scenarios come up constantly in our customer base:

Vendors receiving tickets from customers who run their own JSM. Contract terms require customers to log in to their portal, not yours. Your agents log into 3 or 4 external instances every morning to check for new requests.

First-line to second-line handoff. A public-facing JSM desk handles initial triage; complex tickets go to a specialist team on a second instance. Right now, agents copy-paste details manually and check both systems for updates.

MSPs supporting clients who each run their own JSM. Onboarding a new client takes weeks instead of days, and every client ticket needs to land in your central queue with consistent priority mapping, without giving clients admin access to your instance.

Parent/subsidiary visibility. Subsidiaries run separate JSM tenants for compliance or billing reasons, but the parent company needs visibility into specific subsets: security incidents, executive escalations, or SLA breaches.

What stays private, and what crosses?

This is always the first question, and it's the right one to be cautious about.

With Exalate (available on the Atlassian Marketplace), you control what syncs at the comment, field, and request-type level, independently on each side of the connection. Public comments can cross, while internal agent notes stay in your system. You decide which fields move and how their values translate before anything goes live.

The internal comment risk I mentioned above is handled explicitly: you write and test the mapping rule that keeps internal notes internal, and you verify it in a Test Run before it touches any real customer ticket.

How to set up the sync

The configuration follows this sequence with Exalate:

1. Connect each JSM instance independently. Each tenant authenticates with its own credentials using OAuth.
2. Scope what syncs using JQL triggers. For a vendor handoff scenario, that looks like: project = "SUPPORT" AND labels = "vendor-handoff" . You decide exactly which tickets cross.
3. Write outgoing and incoming sync rules. The outgoing script defines what leaves your JSM. The incoming script defines how arriving data lands. Each side owns its own script, so a workflow change on the partner's side doesn't break your sync. If you'd rather not write Groovy, Exalate's built-in AI assistant generates the script from a plain-English prompt: something like: "Sync request type, priority, and public comments only. Skip internal notes." Review the output before publishing.
4. Run Test Run before publishing. This shows the field-by-field result and the actual payload that would cross. You catch misfires like an internal note appearing as a public comment before any of it reaches a customer.
5. Use version history to roll back if needed. Every published change is tracked with a full audit trail.

Build it yourself, or use a tool?

Any good engineer can build a proof-of-concept JSM integration from the REST APIs in a few weeks. I've seen it done. The real cost shows up 6 to 12 months later.

An Atlassian API change shifts how a field behaves. A JSM workflow edit on one side breaks an SLA mapping on the other. The engineer who built it has moved on. There's no audit log, no rollback mechanism, and no one owns it anymore.

A configured Exalate connection takes hours, not months. It handles edge cases, API updates, audit logging, and cross-instance security out of the box. We maintain marketplace partner status with Atlassian, which means we get early access to API changes before they affect your sync.

Exalate works with Jira Software and Jira Service Management, Cloud and Data Center. You can find it on the Atlassian Marketplace.

What to check before you configure anything

Three things to get clear before you start:

• Which comments should cross (public only, or both)?
• Which fields carry customer or SLA context that must not be dropped?
• Does your partner need independent control of their sync rules, or are you managing both sides?

span class="c0" >The answers to those 3 questions determine your configuration. If you're dealing with SLA mismatches specifically, drop your setup in the comments, and I'll point you to the trigger and mapping logic that fixes it.

span>

Happy to discuss your specific use case.