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, and Jira Product Discovery. 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.  If you're signing up with your Google profile, your account will be created and verified via Google authentication.
6. Log in to 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 connect System A (Jira A)
   
   1. Enter the system URL [https://example.atlassian.net].
   2. A console status check runs automatically.
   3. If the system is already set up, you'll see a confirmation message and can skip authentication.
   4. If the system is being authenticated for the first time, you'll see the Jira Cloud OAuth option.
   5. 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.
      Note: You can also enable the Forge extension for advanced Jira use cases, like comment impersonation. Check the details here. 
5. 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.
6. 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.  
7. 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".
   
8. Click Next to review your configuration.
9. Look over the connection details. Confirm the connection name and description.
10. Click Create Connection to start the setup.
11. Exalate registers your systems automatically and sets up the connection. You'll see real-time updates as the process runs.
    
12. Once it wraps up, click on Continue to Configuration to proceed.
13. 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.
    
14. Click Build & Continue to complete the configuration.

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. Click Publish & quick sync.
2. Under "Item sync monitor," type in the work item key and click Sync Now.
   
3. To link 2 existing items, click Link with existing.
4. Once the sync completes, you can view both synced work items in a new window. You can also compare changes side by side.
5. To use Edit & Test Sync, follow these steps.
   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, click on + New Version to create a new draft version. This way, you don't accidentally edit the active configuration.
8. Click the Edit Script 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 your edits.
11. Or click Start Test Run to test your configuration (more about that later).
12. Click Publish Version when you want to activate the configuration.
13. 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.
14. All configuration versions for a connection are listed under the Version dropdown below the connection name.
15. Versions have these statuses:
    

• Live: 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 + 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 icon (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, it's time to test-run them before publishing. 

1. Open the connection, then click on Edit Script >Start Test Run to validate.
2. Click on Select Items to pick the work items you want to test (you can select multiple). Click Start Test Run to preview how the configuration will be applied.
   
3. 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.
   
4. 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. Click Save Trigger to save changes and publish the trigger.
   

Your integration is now active. Synchronization runs automatically based on your configured sync rules and triggers.

Troubleshoot with Aida

1. Navigate to the “Troubleshooting” tab in your workspace.
2. Hover over any error and click the Aida icon for immediate analysis. Aida shows affected systems, connections, and work items, plus a brief explanation of the error.
3. For deeper investigation, click “Error Details” to view the impact level, stack trace, error type, and occurrence date.
4. Use “View Full Analysis” for complete context. Once you’ve resolved the issue, click “Resolve” to clear the error.

Your integration is now active. Synchronization runs automatically based on your configured sync rules and triggers.

Advanced Jira to Jira Integration Use Cases (Using Aida)

Exalate supports AI-powered Jira-to-Jira integration thanks to the scripting assistant 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.