Jira to Jira Integration

If your team uses Jira and you need to share work with another team or company that also runs on Jira, you'll quickly hit a wall. Native tools work fine within one site, but the moment you're dealing with two separate Jira instances, things get messy. You either pay for extra licenses, copy-paste tickets manually, or build something custom and pray it holds up.

A Jira to Jira integration solves this by connecting multiple Jira instances so work items, comments, statuses, and custom fields stay in sync without anyone needing access to the other side.

Exalate makes this setup possible across Jira Software, Jira Service Management, Jira Product Discovery, and Jira Work Management. It also supports Cloud, on-premise, and Docker deployments. 

Exalate Ramp-up and Configuration Steps

Here's a quick walkthrough of how to get an integration running between two Jira instances.

Create an Account or Log In to Existing Account

1. Head over to the Exalate app.
2. Sign up using Google (SSO) with a company email or create your own account.
3. Click Create an account and fill in your details (business email, first name, last name, strong password).
4. Confirm your password and click Create an account to move forward.
   
5. Verify Your Email: Look in your inbox for a verification message from New Exalate (the verification link expires after 2 hours).
6. Click the link in the email. You'll be redirected to finish your account setup.
7. Log in to New Exalate with your email and password. 

Create a Connection Between Two Jira Instances

1. Log in to your account.
2. Click Add Connections > Create New Connection.
   
3. The connection creation wizard opens, walking you through a 5-step process.
4. To configure System A (Jira A):
5. 1. Enter the system URL [https://example.atlassian.net].
   2. A console status check runs automatically.
   3. To configure System A (Jira A):
   4. Enter the system URL [https://example.atlassian.net].
   5. A console status check runs automatically.

      If the system is already in your workspace, you'll see a confirmation message and can skip authentication.

   6. If the system is brand new, the authentication fields show up automatically.
   7. Go through Jira Cloud OAuth authentication.
   8. Click Check Authentication and wait for it to validate. If you have multiple Jira sites, choose the one you want to use for this connection. Once it's successful, the Next button becomes active.
6. Click Next to move to System B (Jira B). Follow the same steps as System A:
   1. Enter the system URL for your second Jira instance.
   2. Wait for the automatic system type detection.
   3. Provide authentication credentials (OAuth for Jira Cloud).
   4. Click Check Authentication to verify.
   5. Click Next to continue.
7. Name your connection something unique and descriptive. If the name already exists, you'll get an error message asking you to pick a different one.  
   
8. Add a short description so it's clear what the connection is for, like "Sync feature development work items between our internal Jira and partner agency Jira
9. Click Next to review your configuration.
10. Look over the connection details. Confirm the connection name and description.
11. Click Create Connection to start the setup.
12. New Exalate registers your systems automatically and sets up the connection. You'll see real-time updates as the process runs.
    
13. Once it wraps up, you'll see a success message, and your connection status will change to "Ready to configure."
14. After your connection is created, choose which projects to sync between your two Jira instances. Note: Both sides need a project picked before sync rules can be tested.

Configure Your Bidirectional Jira to Jira Connection

You've got two paths from here: Quick Sync and Edit & Test.

The Quick Sync option lets you sync a single work item between Jira instances.

1. Under "Item sync monitor," type in the work item key and click Sync Now.
2. To link 2 existing items, click Link with existing.
   
3. Once the sync completes, you can view both synced work items in a new window. You can also compare changes side by side.
4. To use Edit & Test Sync, follow these steps.
5. 1. Go to your console and find the connection in the Connections list.
   2. Click the connection name or the Edit button to open the configuration page.
      
      
6. On the connection configuration page, you'll see the current sync rules.
7. To change them, create a new version or pick Open latest draft. This way, you don't accidentally edit the active configuration.
    
8. Click the Edit button to open the editor.
9. Edit sync rules using Aida (the outgoing script holds the values passed from Jira A to Jira B, and the incoming sync defines how the values from Jira B are mapped in Jira A).
10. Click Save Script to save the version, or Start Test Run to test your configuration.
11. Click Publish Version when you want to activate the configuration.
12. Click the “Switch Direction” button to modify sync rules for the opposite flow (for example, if you want to edit the incoming script of Jira A and the outgoing script of Jira B). This creates a new version (or draft) for that direction, which also needs review and publishing.
     
13. All configuration versions for a connection are listed under the Version dropdown below the connection name.
14. Versions have these statuses:

• Active: The currently published configuration.

• Draft: An editable copy of the Active version.

• Archived: When a new version is published, the previous Active version gets archived. Restore an archived version by selecting Restore version.

AI-Assisted Configuration with Aida

1. Go to your connection.
2. Click Add new version (or open the latest draft).
3. Click Edit to enter the script editor.
4. In the Aida input field, type your request in plain language.
5. Click the send button (or hit Enter).
6. Aida starts drafting your script.
7. Review the suggested changes. Green highlights show new lines to add, red highlights show lines to remove.
8. Click Insert to accept or Discard to reject.
    
   For Outgoing scripts: Describe what data should leave your system. "Only sync work items with the label 'partner-share'."
   For Incoming scripts: Describe how incoming data should be applied to your system. For example, "Map work item types from Bug to Defect".

Test Run: Validate Before Production

Once your sync scripts are ready, click Start Test Run to validate them.

1. Pick the work items you want to test (you can select multiple). Click "Start Test Run" to preview how the configuration will be applied.
2. Review incoming and outgoing replicas for each test item. Check that field mappings look right. If something's off, go back, tweak the scripts, and test again.
3. Deploy only when you're confident everything works. Click Publish Version to apply the updated configuration to live synchronization.

Automate Jira to Jira Integration Using Triggers

Triggers decide which work items automatically sync based on conditions you set.

1. Click + Add trigger to create a new trigger.
2. Add trigger conditions using Jira Query Language (JQL). Some examples:

   1. project = SUPPORT AND labels = engineering

   2. labels = partner-share AND status = "Approved"

   3. issuetype = Bug AND resolution = "New Bug"

3. Activate triggers by toggling them on. Save changes by publishing.

Advanced Jira to Jira Integration Use Cases (Using Aida)

Exalate supports AI-powered Jira-to-Jira integration thanks to the scripting engine called Aida. If you want to script yourself, check out some Script Helpers so you don't have to do everything from scratch.

Here are common use cases for Jira-to-Jira integration.

Use Case 1: Reduce External Developer Licensing Costs

A frequent pain point for companies that work with external development partners is that they end up paying for Jira licenses for every developer on the partner's team. The reasoning is usually that the partner needs access to your instance to deliver the work.

With a Jira-to-Jira sync, your partner stays on their own instance, your team stays on yours, and only the relevant work items move between them. No extra user licenses, no security headaches around external access.

A prompt to Aida might look like this:

The output would be something like:

if(issue.labels.contains("partner-dev")) { replica.summary = issue.summary replica.description = issue.description replica.status = issue.status replica.attachments = issue.attachments replica.comments = issue.comments.findAll { !it.internal }}

This way, your product owners on one side and the external developers on the other can work on the same shared tickets without anyone crossing into someone else's instance.

Use Case 2: Connect Customer Support and Development Teams

If you're running Jira Service Management (JSM) for customer-facing support and Jira Software for product development, you probably know the back-and-forth pain. 

A support agent gets a bug report, files a ticket, then has to manually create a matching item in the dev project, and then keep both updated as developers investigate.

A bidirectional sync handles this automatically. When a support agent identifies a bug in JSM, it auto-creates a linked work item in Jira Software. Status changes, comments, and resolution info from the dev side flow back to the JSM ticket so the support team can keep the customer in the loop.

A prompt to Aida for the JSM-to-Software side could be:

Use Case 3: Map Work Item Types Between Different Workflows

Two Jira instances rarely use identical work item types or workflow names. One side might call it a "Bug," the other "Defect." One uses "Story," the other "User Story." 

If not mapped correctly, the sync fails or creates the wrong type of item.

A simple type mapping script handles this on the incoming side.

The prompt to Aida:

The script Aida generates:

def typeMapping = [ "Bug" : "Defect", "Story" : "User Story", "Task" : "Task"]def remoteTypeName = replica.type?.nameissue.type = nodeHelper.getIssueType(typeMapping[remoteTypeName] ?: "Task")

If you want, you can do the same for status fields, priorities, or any other field where the two instances use different naming.

Use Case 4: Selectively Share Comments Between Instances

A common request from teams collaborating across instances is for each side to keep some comments private and share others publicly. The pattern that usually works is prefixing shared comments with something like "(SHARED)" so the sync knows what to forward.

The prompt to Aida:

Aida generates something like:

replica.comments = issue.comments.findAll { it.body.startsWith("(SHARED)") }.collect { it.body = it.body.replaceFirst("\(SHARED\)\s*", "") return it}

This pattern shows up a lot with two-company collaborations where teams need a default privacy setting but want a quick way to opt comments into the shared view. The same idea works for attachments or any other field where you want a tag-based filter.

Use Case 5: Hub-and-Spoke for Companies Working with Multiple Partners or Suppliers

Some companies need to work with several external Jira instances at once. Maybe you outsource to two consulting firms, or you're an MSP supporting multiple clients, or you handle multiple suppliers and don't want any of them seeing each other's data.

The setup looks like a hub: your central Jira instance connects independently to each partner's Jira. Each connection has its own sync rules and triggers, so you decide what flows where.

A telecom company used this multi-Jira setup to coordinate internal teams and external partners across instances. A global insurance company does the same with multiple suppliers, building "safe islands" where each supplier sees only their own work.

A typical trigger setup for routing might look like:

Each trigger fires only on items tagged for that specific partner, so there's no chance of Partner B seeing Partner C's work.

Use Case 6: Sync Sprints, Epics, and Custom Fields for Joint Delivery

When a vendor and a client collaborate on a release, both teams often need visibility into sprints, epics, and progress against custom fields like delivery dates or QA status. Manually keeping these aligned across two Jira instances is tedious and error-prone.

Exalate can sync sprint assignments, epic relationships, and any custom field with the right script. For sprints, the incoming sync ensures the work item lands in the correct sprint on the receiving side. For epics, parent-child relationships are preserved.

A prompt to Aida for syncing a custom "Delivery Date" field along with sprint info:

Aida generates:

issue.sprint = nodeHelper.getSprint(replica.sprint?.name)issue.customFields."Delivery Date".value = replica.customFields."Delivery Date".value

This is the kind of setup used by a cybersecurity MSSP to maintain strict boundaries between their operations and client systems while still keeping joint deliveries on track.

Note: The code snippets might not work exactly as written depending on your environment and field names. If you run into issues, reach out for help.

Supported Jira Cloud and On-Premise Entities

Check out the comprehensive list of supported Jira Cloud and on-premise entities.

This is a sample mapping between two Jira work items:

Jira A work item <> Jira B work item

• summary ↔ summary

• description ↔ description

• priority ↔ priority

• status ↔ status

• reporter ↔ reporter

• assignee ↔ assignee

• comments ↔ comments

• attachments ↔ attachments

• labels ↔ labels

• components ↔ components

• fix versions ↔ fix versions

• sprints ↔ sprints

• epics ↔ epics

• subtasks ↔ subtasks

• time tracking ↔ time tracking

• custom fields ↔ custom fields

• third-party plugin fields

• any field available via REST APIs

Other Resources

• Start a free trial with Exalate, or book a call with our integration engineers to walk through your specific use case.

• Using Exalate Classic? Learn more about the difference between Exalate Classic and New Exalate.

• Visit our Trust Center for more security information.

• Got configuration-related questions? Get answers on the Exalate Community

• Join our latest Sync Room Webinar series, where we dig into integration pain points, the latest AI trends in the integration space, and more.