You Can Sync Two Jira Projects in the Same Instance. Here's How.

[Syed Majid Hassan -Exalate-]

Working with a lot of Jira admins myself, I relate to how tricky it is to sync work items between two projects (now called Spaces) inside the same Jira instance. Both projects live under one Jira admin, and a connector keeps selected work, fields, comments, and statuses in step between them.

The typical Jira to Jira connection involves syncing your instance with your partner’s, or Jira to another ITSM or CRM tool under a remote connection. 

The local connection is quite different, and for a lot of Jira admins, it solves the problem of manual copy-paste or a tangle of automation rules.

Let me walk through what a local connection is, when you'd reach for it, and the real patterns we see with Exalate.

What's the difference between a local and a remote connection?

Under Exalate, a local connection links two projects within one Jira instance, whereas a remote connection links two different Jira instances or sites (often across two different companies).

The mechanics are the same on both: each side runs its own outgoing and incoming sync rules, so each project controls what it sends and what it accepts. 

The difference is scope. With a local Jira connection, there's only one instance to authenticate, one set of admins, and one place to manage everything. 

You skip the identity translation across tenants and the negotiation over who installs what. You just decide which works move between Project A and Project B, and what they carry. It is also possible to automate the data transfer between both spaces.

That keeps it simple when you need to break down a wall between two teams who refuse to live in the same project, and usually have good reasons not to.

When would a Jira admin actually need this?

You'll recognize this if you've ever been handed two projects that need to stay in sync. The patterns we see most:

• Separating internal work from client-facing work. A dev team runs an internal project with full technical detail; a separate client-facing project shows the customer a clean view. One setup handles what crosses and access control, while keeping the rest private. The client never sees the messy internal thread, and the dev team never maintains two tickets by hand.
• Auto-escalating work from one project to another. When a work's resolution is "New Bug" and its type is "RCA Request," Exalate creates a Bug in the target development project automatically. The escalation criteria are yours to define, and only matching work items cross.
• Teams that operate in silos with different schemas or workflows. Large orgs end up with projects on different screen schemes, workflows, and custom fields. A local connection lets each team keep its own setup and syncs only the data that needs to cross.
• Linking a feature in one project to an epic in another. Native Jira links show the relationship but let the two works drift apart. A local connection keeps them aligned: update the epic's status or a field, and the linked feature reflects it.
• Keeping a dedicated QA project in sync with the dev backlog. Some teams run a separate QA or test project, so testers work in their own board. A local connection auto-creates a test ticket in the QA project when a story hits "Ready for QA," and syncs status back to the devs.
• Giving Scrum Masters a consolidated sprint view across teams. When two squads run in separate projects with their own boards, a scrum master ends up flipping between them to track cross-team dependencies. Using a local connection helps the scrum master to sync every sprint, story, and status field as a single, accurate picture.

What about status and field mismatches between the two projects?

I've personally worked with teams running multiple internal projects misaligned on priority, statuses, and custom fields, where every manual sync attempt broke because the data didn't line up.

Here is a common scenario: One project uses "To Do / In Progress / Done" while the other has six custom transitions and three mandatory fields. 

Exalate handles this with status mapping and field mapping on each side. You write a small rule ("when their status is X, set mine to Y") to prompt the AI assistant, Aida, and the code is generated for you instantly. 

Fields work the same way; their "Severity" maps to your "Priority," and anything you don't want gets ignored. Each side controls its own incoming rules; neither team is forced to standardize. 

For simple, same-workflow cases, Jira automation can clone your work and copy a few fields as they are. If that covers you, use it.

But if you’re maintaining mappings across teams that keep changing their own setups, you’d need an integration solution to supplement or replace the native option.

How do you set one up?

At a high level:

1. Head to the Exalate console and connect your Jira instance. 
2. Create a local connection by entering and authenticating the URL of your Jira instance, then pick the two projects from both sides.
   
3. Use the scripting assistant Aida to configure and define the outgoing rules (what each side sends) and incoming rules (how each side maps what it receives), including status and field mappings. You can also choose to script yourself.
   
4. Set a trigger on the source side, a JQL query that scopes what syncs. For example, project = SUPPORT AND labels = escalate-to-dev so only flagged work items are shared, not the whole project.
5. Use Test Run to preview the sync against the draft config before it touches live works, then publish when you're confident.
6. Use Script versioning to track every published change. Roll back changes if a mapping goes sideways, especially when you're editing rules on a live connection.
7. Use Sync Panel to check the status of your connections and bring sync error visibility directly into your browser.

The scripts provided by Exalate are Groovy-based, and users can edit the scripts themselves with the assistance of Aida (scripting assistant)

Key takeaways for Jira admins

• A local connection syncs two projects inside one Jira instance: single admin, independent project control, no cross-instance overheads.
• The most common use case involves auto-escalating work from one project to another based on your defined criteria (trigger conditions).
• It shines when two projects have different workflows, schemas, or custom fields and you can't (or won't) merge them.
• Status and field mapping per side means neither team has to standardize on the other's setup.
• Scope what syncs with a JQL trigger, preview with Test Run, and roll back with script versioning.

If you've got a project-to-project setup you're wrestling with, especially weird status mismatches, discuss with me to learn more, try Exalate already, or drop your use case in the comments section below.