Community resources
Community resources
Community resources
Enabling Interagency Collaboration Across the Atlassian Ecosystem: How Government Agencies Sync Sepa
I'm Francis, CEO of Exalate. We build the two-way Jira sync used in the scenarios below.
Two agencies working on the same project almost never run the same setup. One might be on Jira Data Center, the other already moved to Jira Cloud.
One might use a systems integrator with its own backlog, while the agency tracks approvals somewhere else entirely.
Security policy usually blocks either side from logging into the other's instance.
This is the default state for most interagency and agency-to-contractor work in government.
We ran a webinar with Clovity and Carahsoft last week,
Enabling Interagency Collaboration Across the Atlassian Ecosystem.
My colleagues Megan Floyd, our business director, and Christophe De Beule, one of our solutions engineers, walked through three patterns alongside Samar Shah, a customer success partner at Clovity.
I want to break them down here because they map to almost any cross-instance government project I've come across.
Can two Jira Data Center instances stay in sync without either side getting access to the other?
Yes, and this is probably the most common ask we get from state agencies.
Picture two state DOT agencies running a joint, federally funded, multi-year bridge project. Neither can manage it alone. A delay on one side changes the schedule on the other. But neither wants the other logging into its Jira Data Center instance, because vendor data, internal comments, and other sensitive fields shouldn't cross the fence.
The setup we demonstrated syncs tickets, comments, statuses, and attachments between the two instances directly, without granting access either way. Each side decides what leaves its instance and what stays internal. No new licenses, no infrastructure changes on either end.
Internal comments stay internal by default. Status mappings are configured per side, so "in progress" on one instance can map cleanly to whatever equivalent status the other side uses.
In the demo, Christophe set this up with a JQL-based trigger, not a blanket sync. The rule was narrow on purpose: only tickets of a certain type, moved to "in progress," get picked up. Everything else stays untouched until someone explicitly runs a bulk sync against a JQL filter.
The status mapping was about getting "in progress" reflecting correctly on both sides. Once that's set, priority changes, comments, and status updates all flow automatically going forward. If a ticket doesn't exist yet on the other side, the script can create one on the fly instead of erroring out.
What happens when a contractor and an agency work in two different cloud instances?
This is the one I'd flag if your agency is mid modernization right now.
A state HHS agency modernizing an eligibility platform brought in a systems integrator to own the backlog. The integrator tracks development work in its own Jira Cloud instance.
The agency tracks approvals in a separate one. Nobody wants the agency inside the contractor's tenant, and the contractor doesn't want agency staff inside its own either.
The gap that creates is obvious. Who knows if a defect got fixed, or an approval went through, without someone asking?
The sync we showed closes that gap in close to 20 seconds per update. A label change on one board triggers the sync, and the update shows up on the other side automatically, including priority changes, comments, and attachments. Non-public, internal comments still don't cross over unless you configure them to.
The two sides didn't even have matching issue types. The agency's ticket type didn't exist on the contractor's board, so Exalate mapped it to the closest available type automatically instead of blocking the sync.
Assignee synced over as well, though for the reporter field, agencies often proxy that to a shared service account rather than exposing whoever's actually working the ticket. Attachments came through too.
Our two agencies are on different cloud migration timelines. Does that block collaboration?
No, and this one comes up more than people expect.
State agencies migrating to Jira Cloud rarely move on the same schedule as the agencies they work with. One agency moves ahead. The neighboring one isn't ready, and its timeline has nothing to do with yours. Without a sync, someone ends up manually recreating tickets, sitting in status meetings, and waiting on updates that should already be visible.
We showed a Jira Cloud to Jira Data Center connection carrying over epics, their child issues, and the links between them, so migrating one side doesn't mean rebuilding what the other side already has. A bulk sync moves a batch of existing tickets over in one pass, and anything created after that syncs automatically going forward.
The bulk sync runs on a FIFO queue, so with several epics migrating at once, you can watch each one move through "waiting for remote" to "synchronized" in order. Each migrated ticket gets a reference field pointing back to its counterpart on the other instance, so anyone can jump straight to the linked ticket instead of searching for it.
The child-issue piece required pulling the parent epic's ID into the outgoing sync so new tasks land under the correct epic on the other side automatically, instead of someone manually re-linking every child issue after migration.
Who decides what data gets shared across agencies?
Not us, and not the systems integrator either. That call sits with your agency's own governance: your SLAs with the contractor or partner agency, and whatever your security or IT leadership has already signed off on.
What the sync actually does is give you the controls to enforce that decision. You choose what leaves your instance in the outgoing sync. The other side chooses what leaves theirs. Neither of you inherits a call the other side made.
How long does a setup like this actually take?
For the ongoing ticket sync, four to six weeks is typical, depending on how many custom fields and status mappings you're dealing with. Full data migrations, especially ones moving thousands of tickets from Data Center to Cloud, take longer. Months, not weeks, in some cases.
There's no requirement to bring in an implementation partner to get this running. If you're already working with a systems integrator like Clovity on the bigger modernization project, they can help with the mappings. If you're doing it yourself, the setup runs on Groovy script, and Christophe put the share of use cases needing anything beyond that scripting at well under 1%.
Before you sign off on another manual workaround
If your agency is running a joint project with another agency, a contractor, or both, and the current plan is "someone checks the other system and reports back", that's the exact gap these three scenarios closed.
None of them required merging instances, migrating on the same timeline, or opening up access either side wasn't comfortable with.
We've written up a broader look at how enterprise and government teams handle this kind of two-way sync here, and a step-by-step on setting up a straight Jira to Jira connection here.
The Exalate connector discussed in this article is available here.
Was this helpful?
Thanks!
francis
1 comment