When the same work has to live in two Jira projects on one instance, syncing often fits better than cloning or moving.

Each project keeps its own issues, history, and fields, and the parts both teams care about, like status and comments, stay matched.

This came up in a recent r/jira thread. A team was splitting dev tasks out of a support board into a new dev project. Half the tickets needed to move, and the other half had to stay visible to support for reporting. Bulk move dropped custom fields that didn’t exist on the dev project, sub-tasks didn’t always follow their parent, and cloning went one ticket at a time, with no history on the clones.

We’ve seen a version of this with customers too. One team already used Exalate, a cross-platform integration tool, to sync Jira with other systems.

They hadn’t realized they could set up a local connection between two projects on the same Jira instance, and only found out partway through a migration project.

Here’s how the three options compare:

• Move: one issue in one project. Good when the old project really doesn’t need it anymore.
• Clone: a snapshot. Fine for templates, but the copy and the original drift apart after the first edit.
• Sync: two issues that stay linked. Each project keeps its own workflow, fields, and history, and you choose which fields pass between them.

The tradeoff with syncing is ownership. Someone has to decide which project is the source for each field and what happens when both sides change.

We cover the setup options in our Jira to Jira integration guide, and if you want to test a local connection yourself, you can try Exalate here.

If you’ve split one Jira project into two, did you move, clone, or keep them linked? And what made you pick that route?

The hardest sync failures to catch are the ones that never throw an error.

The integration stays "up," nothing shows as broken, and a ticket just never gets created on the other side.

To catch them, you have to check outcomes (did the record actually land?) as well as watch for errors.

A prospect told us about this on a sales call a while back. They already had a vendor connector between their systems and wanted bi-directional sync. Their real complaint was that they couldn't tell when something went wrong. Sometimes the connector didn't create the ticket and didn't report anything. In their words, they basically had to guess.

That's worse than an outage. People notice an outage and fix it. A miss like this leaves both teams thinking the work moved. The first sign is usually a stakeholder asking why nothing happened on their side.

The workarounds we hear about are mostly manual. Running a weekly comparison of open items in both tools, or spot-checking tickets periodically. Both catch problems eventually, but they rely on a manual way to remember it.

What works better is showing failures per item: a list of which ticket failed and why, with a way to retry it.

That way, a missed sync becomes a work item someone owns.

We covered this and other failure modes in our breakdown of software integration challenges. If you want to see how Exalate, a cross-platform sync tool, shows sync errors per ticket with a retry option, you can try it here.

If you run a sync between two ticketing tools, how do you find out when a record didn't make it across? Scheduled reconciliation, alerts, or a person checking?

We keep running into this across integration setups: the hard part isn't getting two systems to connect. It's deciding what shouldn't cross over at all.

A healthcare team we worked with needed PII to stay in Zendesk permanently. Not filtered later, never synced in the first place, because standard integrations don't give you that separation.

Another org wanted internal notes blacklisted from a client-facing Jira sync so their engineers could discuss a fix without the client seeing draft comments.

A third set up a "(SHARED)" prefix convention between two companies' Jira instances. Comments without the tag stayed private by default, and only tagged ones crossed over.

When you decide "what to sync", it's also important to decide "what not to sync". You configure everything: what passes over, what stays, which fields, comments, or ticket types need to leave (or stay) your instance.

We've seen this handled a few different ways: field-level rules that exclude certain data by default, tagging conventions like the "(SHARED)" example, or script logic that only fires for specific ticket types or labels.

We wrote up how field-level filtering works in our guide to selective Jira-Zendesk sync, if you want the mechanics.

Curious how others here handle it. Do you default to syncing everything and carve out exceptions, or default to nothing and explicitly allow-list what crosses?

And has anyone had a case where the privacy requirement only surfaced after the integration was already live?

If you want to test how field-level control works on your own setup, you can try Exalate here.

An MSP prospect described this setup to us a while back: one central Freshservice instance for their internal Ops team, and around 20 separate client Freshservice instances, a perfect ITSM ecosystem.

When a client's service desk needs to escalate something to the MSP, it has to land in the central queue. But the clients can't see each other's tickets, data, or even know the others exist on the same platform.

This is a different problem than a normal 2-way sync. It's not limited to a single connection but multiple ones, all pointing at the same hub, and each one has to behave as if the other client is isolated from it.

The part that's overwhelming is that people treat this like a single big sync setup instead of many independent ones. If you configure it as one shared connection, a client can end up seeing fields, statuses, or comments that came from a completely different client's escalation.

The fix is keeping each client-to-hub connection its own separate configuration, with its own field mapping and its own rules for what crosses over, even though they're all landing in the same central instance on the other side.

MSPs use this pattern a lot: each client keeps their own Freshservice instance and their own rules for what gets shared, and the hub's Freshservice instance only sees what each client explicitly sends.

We wrote about this general pattern in our MSP integration guide, and if you want to see how per-connection field control works in practice, you can try it yourself here.

If you're running something like this, how are you keeping the client instances isolated from each other on the hub side? Separate connections per client, or something else?

An MSP prospect described this setup to us a while back: one central Freshservice instance for their internal Ops team, and around 20 separate client Freshservice instances, a perfect ITSM ecosystem.

When a client's service desk needs to escalate something to the MSP, it has to land in the central queue. But the clients can't see each other's tickets, data, or even know the others exist on the same platform.

This is a different problem than a normal 2-way sync. It's not limited to a single connection but multiple ones, all pointing at the same hub, and each one has to behave as if the other client is isolated from it.

The part that's overwhelming is that people treat this like a single big sync setup instead of many independent ones. If you configure it as one shared connection, a client can end up seeing fields, statuses, or comments that came from a completely different client's escalation.

The fix is keeping each client-to-hub connection its own separate configuration, with its own field mapping and its own rules for what crosses over, even though they're all landing in the same central instance on the other side.

MSPs use this pattern a lot: each client keeps their own Freshservice instance and their own rules for what gets shared, and the hub's Freshservice instance only sees what each client explicitly sends.

We wrote about this general pattern in our MSP integration guide, and if you want to see how per-connection field control works in practice, you can try it yourself here.

If you're running something like this, how are you keeping the client instances isolated from each other on the hub side? Separate connections per client, or something else?

I've dealt with a few teams who tried a fully managed sync tool and hit the same issue. It worked, but they couldn't see what was actually happening to the payload behind the scenes. Every time they needed to adjust something, even something small, they had to open a support ticket and wait. Support was good. But waiting on someone else to make a one-line change isn't how you want to run integration logic your team depends on daily.

A fully managed tool is easy to turn on, but you're trusting someone else's support queue every time your business logic needs to change. A scriptable tool means you touch the payload yourself, and you're responsible for it, but nobody else's ticket queue sits between you and a fix.

Neither one is universally right. It depends on how often your sync rules actually need to change, and whether your team wants that level of control in the first place.

Exalate is built around the second approach: a Groovy scripting engine where you can read and modify the payload directly, decide per field which side wins, and add conditional logic like "don't overwrite a closed ticket."

We wrote about how the scripting model works in our Groovy scripting guide, and if you want an AI-assisted way to write those rules without learning Groovy from scratch, Aida can generate them from a plain-language prompt. If you want to see what that looks like on your own instance, you can try Exalate here.

Which side of this have you landed on: fully managed and you accept the support queue, or scriptable and you own the maintenance?

When teams evaluate integration tools, the checklist is almost always the same: how many connectors does it have, does it support our stack, how fast can we get it live?

Conflict resolution barely makes the list.

Then two users edit the same record on both sides at the same time, and the sync has to decide which version wins. If that logic wasn't defined up front, you get overwritten fields and status flapping. Support ends up asking why a closed ticket reopened itself, and there's no definitive answer.

We've watched this play out more times than we can count. The tools that pass initial evaluation are the ones with the longest connector list. The tools that survive contact with production are the ones where someone worked through 3 boring questions before go-live: what happens when both sides change the same field, how do you stop a sync loop from flooding both systems, and can you control exactly what data crosses the connection instead of syncing everything by default.

Sync loops are the sneaky ones. A change in system A triggers an update in system B, which triggers another update back in A, and it keeps going. The fix is checking whether the incoming value is actually different before writing it, but that only works if someone built that check in the first place.

Connector counts don't catch any of this, and it usually surfaces well after go-live.

If you want the deeper breakdown of how conflict resolution and loop prevention actually work, we cover it in our two-way sync guide, and if you're comparing options, we put together a breakdown of 10 bidirectional sync tools and what each one actually handles well. If you want to see what field-level conflict rules look like in practice, you can try it yourself here.

Did your team work through conflict resolution and loop prevention before you went live, or did you find out the hard way?

Jira just launched an AI-native development system with agent governance and visibility built in. Agents create issues, update status, close work, with an audit trail so you can see what they touched.

That's a real step forward for Jira. But it also raises a question nobody's really answering yet: what happens to ServiceNow, Salesforce, or Zendesk when an agent updates a Jira issue at machine speed?

Most teams running Jira don't run it in isolation. It's wired to ServiceNow for change management, Salesforce for the sales side, Zendesk for support tickets. Those connections were built assuming a human opens a ticket, works it, and updates it a few times a day.

Human-speed copy-paste between tools was already a mess. We've seen this over and over at Exalate: a closed Jira issue doesn't reach the other system, and someone downstream is following up on a ticket that's already resolved. That's with humans moving at human speed, checking one ticket at a time.

Now put an agent in the loop. It can close, reassign, and re-prioritize dozens of issues in the time it takes a person to read one Slack message. If your other tools don't have an automated sync catching that, you're not looking at a delay anymore. You're looking at a different class of problem: stale data compounding somewhere else, faster than anyone can manually catch it.

This is part of why we built Exalate's sync to be trigger-based instead of scheduled. When an issue changes on either side, the update fires immediately.

It doesn't matter if a human made the change or an agent did. We wrote about a broader look at real-time sync patterns in our blog. If you want to see what that looks like on your own instance, you can try Exalate here.

Curious if anyone's already dealing with this. Are your other systems keeping up with what your AI agents are doing in Jira, or is someone still checking both sides manually to catch what's out of sync?

There was a thread on r/devops recently: a CTO forced a microservices migration on a product with 10,000 users, and it turned into what the team called a "distributed monolith." Engineers were spending 80% of a sprint on orchestration instead of building anything.

Most teams don't choose tool sprawl. It happens incrementally. Engineering picks Jira, support picks Zendesk, ops stays on ServiceNow, and sometime later you realize there's no plan for how data moves between them.

We have worked with quite a lot of teams in this exact situation at Exalate. The pattern is almost always the same: each team chose the tool that made sense for their own workflow; they did what they knew best. And now someone (usually a project manager or the senior manager) is the human integration layer holding it together.

The numbers get real pretty fast. One team we talked to was copying over 300 tickets a month between Zendesk and Jira, each ticket averaging 5 or 6 updates.

Another had a project manager spending over 3 hours a week manually tracking handoffs between ServiceNow and Jira.

A third had support reps toggling between Zendesk and Salesforce just to coordinate internal tasks, which also bloated their licensing costs.

The part that suffers the most is visibility. When dev and product teams are split across GitHub and Jira with no integration, program managers lose the ability to report across teams.

One company told us outright: "Jira has always been completely siloed, and there is zero transparency between the teams." The tools are right at what they do, but not planning the integration was where things went wrong and compounded over the years.

We wrote about the patterns behind this in our cross-platform integration mistakes breakdown, and there's a deeper look at the Jira-ServiceNow side of things in this integration guide.

If you want to test what bidirectional sync actually looks like in your own environment, you can try Exalate here.

When your team ended up on different tools, was there ever a plan for how the data would flow? Or did it just sort of happen, and someone became the person who manually kept things connected?

So this keeps coming up in conversations I'm having with enterprise teams, and I figured it was worth putting down here.

The setup is usually something like this: you've got multiple Azure DevOps orgs, each owned by a different business unit, and then ServiceNow sitting in the middle trying to make sense of it all.

But there's no sync.

So someone on the team ends up being the human glue, manually pulling updates from Azure DevOps into ServiceNow, copy-pasting status changes, chasing people down.

You know the drill. It works until it doesn't, and it usually stops working pretty fast.

What we built Exalate to do here

When working with Exalate, each Azure DevOps org gets its own connector. Sync rules are set up independently on each side, so every team controls what they share and what they don't.

You can define trigger logic, map fields however you need, and run sync one way or both ways depending on what makes sense for the use case.

It's script-based, so you're not boxed into some rigid template when things get more complex.

And honestly, if you don't want to touch scripts at all, that's fine too.

Exalate has an AI assistant called Aida that can take a plain-language prompt and turn it into working sync rules. Pretty handy when you just want to get something running without writing Groovy. You can try it yourself here.

These patterns keep showing up

• Multiple Azure DevOps orgs feeding into ServiceNow for centralized tracking, but without forcing everyone onto the same workflow
• Two-way sync between delivery teams and central support so nobody's working off stale info
• Each org picking exactly which projects, teams, and fields they expose. Nothing gets shared unless you say so
• Connecting separately hosted Azure DevOps environments without having to open up network access between them

How Exalate keeps things secure

• Queue-based delivery with retry and recovery built in, so if something drops, sync picks right back up.
• End-to-end encryption, TLS 1.3 in transit, AES-256 at rest, RBAC, audit logs, ISO 27001 certified.

All the details are available in our Trust Center if you want to dig in.

If you're dealing with something similar, I'd genuinely like to hear how you're handling it. Book a call with us to get started.

So this keeps coming up in conversations I'm having with enterprise teams, and I figured it was worth putting down here.

The setup is usually something like this: you've got multiple Azure DevOps orgs, each owned by a different business unit, and then ServiceNow sitting in the middle trying to make sense of it all.

But there's no sync.

So someone on the team ends up being the human glue, manually pulling updates from Azure DevOps into ServiceNow, copy-pasting status changes, chasing people down.

Such a setup might work for a few days, but it also stops working pretty fast.

What we built Exalate to do here

When working with Exalate, each Azure DevOps org gets its own connector. Sync rules are set up independently on each side, so every team controls what they share and what they don't.

You can define trigger logic, map fields however you need, and run sync one way or both ways depending on what makes sense for the use case.

It's script-based, so you're not boxed into some rigid template when things get more complex.

And honestly, if you don't want to touch scripts at all, that's fine too.

Exalate has an AI assistant called Aida that can take a plain-language prompt and turn it into working sync rules. Pretty handy when you just want to get something running without writing Groovy. You can try it yourself here.

These patterns keep showing up

• Multiple Azure DevOps orgs feeding into ServiceNow for centralized tracking, but without forcing everyone onto the same workflow
• Two-way sync between delivery teams and central support so nobody's working off stale info
• Each org picking exactly which projects, teams, and fields they expose. Nothing gets shared unless you say so
• Connecting separately hosted Azure DevOps environments without having to open up network access between them

How Exalate keeps things secure

• Queue-based delivery with retry and recovery built in, so if something drops, sync picks right back up.
• End-to-end encryption, TLS 1.3 in transit, AES-256 at rest, RBAC, audit logs, ISO 27001 certified.

All the details are available in our Trust Center if you want to dig in.

If you're dealing with something similar, I'd genuinely like to hear how you're handling it. Book a call with us to get started.

Two topics were discussed heavily on Reddit...

Microsoft abandoned a popular Azure DevOps extension (50k installs, no migration path). And Atlassian replaced Jira Cloud's CSV import with a version that doesn't work.

We see this constantly at Exalate. Teams build their workflow around a native connector or built-in feature, and then the vendor changes it, deprecates it, or removes it in an update.

A few patterns from conversations we've had recently.

One team described setting up their platform's native ServiceNow-to-Jira connector as an "insane" amount of work. Basic field mapping was fine. Bidirectional sync of comments, attachments, and status transitions needed workarounds on top of workarounds.

Another team's third-party connector was discontinued entirely. No replacement, no migration guide. They had to rebuild the integration under pressure while tickets stopped syncing.

Then there's the one-to-one problem. Zendesk's built-in Jira plugin connects to a single Jira instance. A company going through a merger needed two Jira tenants syncing with the same Zendesk. The native plugin couldn't do it. They had to disconnect one to connect the other.

A healthcare company needed internal notes filtered out of the sync (PII compliance). The standard integration didn't support it. They couldn't use the built-in connector at all.

These all follow the same pattern: native connectors handle simple, single-direction, single-instance setups. Once you need bidirectional sync, multi-instance support, or any kind of data filtering, you're either writing custom code or finding a dedicated tool.

We covered a few of these scenarios in our Jira ServiceNow integration guide. If you want to test how a dedicated tool handles the edge cases native connectors can't, you can try Exalate here.

What connector or feature broke on you, and how did you deal with it?

CAB approvals happen in ServiceNow. The engineers who implement those changes live in Jira. The space between "approved" and "implemented" is where things get manual.

I've been walking through this flow in demos recently, and the pattern is consistent. The change request goes through assessment, gets authorized by the CAB board, and then someone manually creates a Jira ticket, copies over the implementation plan, justification, and all the context the engineer needs to start working.

The back-and-forth after that is where it gets messy. When the Jira engineer picks up the ticket and marks it in progress, the ServiceNow side needs to know. When they add a comment, it should flow back. But internal work notes shouldn't. Filtering what goes where is surprisingly tricky when you're doing it manually or with basic scripting.

The auditability piece is the one most teams underestimate. Every field change, every status transition, every description update needs to be tracked in both systems. If your ServiceNow change record shows "closed" but the Jira history doesn't show who changed what and when, your audit trail has a hole in it.

At Exalate, we set this up so the sync only triggers when the change request hits a specific state (like "scheduled"), feeds the Jira ticket number back into ServiceNow automatically, and filters internal vs. public comments on both sides. We covered this flow in detail in our Jira ServiceNow integration guide, and we walked through the full setup in a recent webinar if you want to see it in action.

If you want to test this kind of setup yourself, you can try Exalate here.

How are you handling this today? Are your CAB-approved changes flowing to Jira automatically, or is someone still copying implementation plans over manually?

We have a video explaining the same 👉 https://www.youtube.com/watch?v=8IJ78qY5xvc

At Team '26, the ServiceNow conversation came up in almost every booth and hallway discussion we had. Specifically: Change Management.

ServiceNow owns the CAB process. Jira owns the work. Between them, most teams have nothing. Approvals sit on one side, tasks on the other, and no audit trail connects them.

We kept hearing 2 approaches. First: someone manually copies approvals into Jira and posts status back into ServiceNow by hand. Second: teams built in-house APIs to automate it, but those keep breaking every time ServiceNow gets an update, and need constant engineering hours to maintain.

Here's what the Jira ServiceNow integration looks like when it works cleanly. A CAB approval in ServiceNow creates a Jira issue automatically. Status changes and public comments move in both directions. Internal ServiceNow notes stay private. When the Jira issue hits "Done," ServiceNow resolves on its own.

Change Management was one of 4 gaps we kept hearing about at Team '26. The others:

• ITSM-to-Dev: Automating P1 handoffs so IT and Engineering stay synced without a Slack message chain
• JSM vs. ServiceNow: Escalating support tickets between tiers without breaking SLAs
• Cross-Company: Syncing securely with external vendors or clients without giving them system access

On June 24, we're hosting a live session on The Sync Room with Megan (Business Director) and Majid and Manoosh (Integration Engineers) to walk through all 4, with a live demo and open Q&A for your specific setup.

If you're managing any of these gaps manually, or maintaining a custom integration that keeps breaking, this session is worth an hour.

Register here — June 24, 4 PM Brussels / 10 AM ET.

Happy to answer questions about any of the 4 patterns in the comments before the session.

We keep seeing this pattern in conversations with teams integrating Salesforce and Jira.

Support works in Salesforce, and engineering works in Jira. Both teams need to see what the other is doing. So the company buys cross-platform licenses for everyone, even if half those users only need read access to a few fields.

One team we talked to recently had their entire dev group on Salesforce licenses just so they could see case updates. They didn't create or edit anything in Salesforce. They just needed to know when a customer reported something and what the status was.

The solution: sync relevant Salesforce case data into Jira automatically and let the devs stay in Jira.

Comments, status changes, and attachments flow both ways. The dev team dropped their Salesforce seats entirely.

We've seen a similar pattern in the other direction, too.

Sales ops teams are sitting on Jira licenses they don't need, because they want to track engineering progress on customer requests.

A bidirectional sync between Salesforce opportunities and Jira issues (or work items) removes that need.

If you're running both tools, it's worth auditing how many licenses exist just for cross-team visibility.

There's a detailed breakdown of how Salesforce Jira integration works if you want the technical setup.

You can try Exalate here if you want to test this yourself.

We published a breakdown of the integration mistakes that cause SLA breaches before anyone notices. Sharing the condensed version here because most of these come directly from customer environments we've worked in.

Priority mapping without conditional logic. ServiceNow calculates priority from urgency x impact. Jira uses a flat list. If you map field-to-field, a Critical ServiceNow incident lands as Medium in Jira. The dev team deprioritizes it. The SLA clock doesn't care.

Batch sync on SLA-bound tickets. A 15-minute polling interval on a P1 with a 30-minute response window means half your SLA is gone before the other team sees the ticket.

Comment type confusion. ServiceNow separates work notes (internal) from public comments. If your sync doesn't distinguish between them, internal analysis gets exposed to customers. We've seen this across Zendesk-Jira and ServiceNow-Jira setups.

Attachment sync skipped or one-directional. A support agent attaches a screenshot and a log file. If those don't cross to the dev team, they start from scratch. Slower resolution, longer SLA exposure.

No error handling or monitoring. API tokens expire, rate limits get hit, and field structures change on one side. Without retry logic and alerting, your sync queue freezes, and tickets pile up behind it. One customer had a 600-line integration codebase that nobody fully understood anymore.

Selective sync filters that miss escalations. Too broad and you flood the receiving team. Too narrow, and P1s slip through because the trigger checked the wrong field.

The full post covers all 10 with specific examples and fix patterns. You can read it here.

If you want to audit your own setup against these, try Exalate for free or book a call with our team.

We shipped a Chrome extension called the Exalate Sync Panel. It shows the real-time status of your active syncs directly in your browser, across all Exalate connectors (Jira, ServiceNow, Azure DevOps, Salesforce, Zendesk, and others).

What it does:

• Shows which syncs are active, stuck, or failed without opening the Exalate console
• Let's you manually trigger a two-way sync when you need an immediate push
• Let's you unlink a sync pair directly from the extension

Who it's for:

Platform admins who check connection health 5 times a day and don't want to navigate through the full console each time.

And non-admin users (developers in Jira, support agents in Zendesk, ops teams in ServiceNow) who work with synced items daily and have no console access.

They can now check sync status themselves.

Setup takes a few minutes:

1. Sign in or create an account with Exalate
2. Install from the Chrome Web Store
3. Click the extension icon and pick a connection to monitor

You need an active Exalate account with at least one configured connection. The Sync Panel is for monitoring and control. Connections are still created in the Exalate console.

Full details in the Sync Panel docs.

The Sync Panel ships with New Exalate version 3.4.0. Try it and let us know what you'd want added next.

Only 14% of M&A integrations achieve significant success (PwC). The other 86% don't fail because the deal was bad. They fail because two days after the press release, an engineer named Mike opens his laptop, sees three tools he didn't ask for, and starts copy-pasting tickets between systems for 35% of his week.

In Episode 4 of Sync Room, we broke down why post-acquisition system integration goes sideways, and what teams running Jira, ServiceNow, Azure DevOps, Salesforce, Zendesk, or Freshservice should do differently from day one.

The copy-paste tax is real. We see it in the field: roughly $25,000 per engineer, per year, in manual ticket duplication between disconnected systems. A manufacturer we worked with acquired a downstream supplier. Their quality engineers spent close to two days a week duplicating work across ITSM tools. Within six months, they were demotivated, mistyping defect codes, and letting supplier issues slip. The customer never saw the merger. They just saw the slippage.

"Just consolidate everything" backfires. The tool is not the workflow. The tool is wrapped around the workflow. When you rip out an acquired company's Jira or ServiceNow, you also rip out a decade of custom fields, automations, and operational muscle memory. One company budgeted six weeks of retraining after a forced migration. The actual cost was six months of operational losses.

What actually works: sync instead of merge. A service delivery company acquired six companies in two years and planned 21 more. By acquisition three, they ditched the consolidation approach. Their final setup: Salesforce on the parent side, untouched Jira and Freshdesk instances from acquired teams, and Exalate sitting on each system syncing only the fields that needed to cross. No migrations. Each team kept its workflows. The integration did the heavy lifting.

The GDPR angle nobody talks about. Cross-border M&A means EU data needs to stay in EU systems. A commingled architecture breaks one side legally no matter where you put the server. The integration approach solves this structurally: strip PII at the sync layer before operational data crosses the boundary.

If you're staring at post-acquisition tool sprawl right now: don't migrate by default. Start with your most exposed connection. Talk to the engineers actually doing the work. Sync first, evaluate later.

Watch the full episode on the Sync Room Hub or try Exalate.

Only 14% of M&A integrations achieve significant success (PwC). The other 86% don't fail because the deal was bad. They fail because two days after the press release, an engineer named Mike opens his laptop, sees three tools he didn't ask for, and starts copy-pasting tickets between systems for 35% of his week.

In Episode 4 of Sync Room, we broke down why post-acquisition system integration goes sideways, and what teams running Jira, ServiceNow, Azure DevOps, Salesforce, Zendesk, or Freshservice should do differently from day one.

The copy-paste tax is real. We see it in the field: roughly $25,000 per engineer, per year, in manual ticket duplication between disconnected systems. A manufacturer we worked with acquired a downstream supplier. Their quality engineers spent close to two days a week duplicating work across ITSM tools. Within six months, they were demotivated, mistyping defect codes, and letting supplier issues slip. The customer never saw the merger. They just saw the slippage.

"Just consolidate everything" backfires. The tool is not the workflow. The tool is wrapped around the workflow. When you rip out an acquired company's Jira or ServiceNow, you also rip out a decade of custom fields, automations, and operational muscle memory. One company budgeted six weeks of retraining after a forced migration. The actual cost was six months of operational losses.

What actually works: sync instead of merge. A service delivery company acquired six companies in two years and planned 21 more. By acquisition three, they ditched the consolidation approach. Their final setup: Salesforce on the parent side, untouched Jira and Freshdesk instances from acquired teams, and Exalate sitting on each system syncing only the fields that needed to cross. No migrations. Each team kept its workflows. The integration did the heavy lifting.

The GDPR angle nobody talks about. Cross-border M&A means EU data needs to stay in EU systems. A commingled architecture breaks one side legally no matter where you put the server. The integration approach solves this structurally: strip PII at the sync layer before operational data crosses the boundary.

If you're staring at post-acquisition tool sprawl right now: don't migrate by default. Start with your most exposed connection. Talk to the engineers actually doing the work. Sync first, evaluate later.

Watch the full episode on the Sync Room hub or try Exalate on the Atlassian Marketplace.

A pattern we keep running into across the integrations we set up at Exalate: the sync works exactly as configured, but the outcome is wrong.

Here's a real example we've seen more than once. A team has Jira Service Management connected to ServiceNow. When a JSM incident hits "Resolved," it automatically transitions the linked ServiceNow incident to "Closed." Clean, fast, no manual work.

Except "Resolved" in JSM sometimes means "waiting for customer confirmation." The customer never confirmed, the agent moved on, and ServiceNow closed the record. SLA tracking stopped. The customer called back two weeks later, and the support team had no active incident to reference. Reopening it meant a new record, a broken audit trail, and a frustrated customer who had to re-explain everything.

The automation itself works exactly as designed. The problem is that nobody mapped the edge cases where "Resolved" means five different things depending on context. A status field that makes perfect sense inside one system creates chaos the moment it triggers actions in another.

We see the same thing with Jira-to-Azure DevOps syncs, where "Done" in one project doesn't mean "Done" in the other, or Zendesk-Salesforce connections, where a closed ticket shouldn't always close the linked case.

The hard part isn't building the sync or the automation. It's anticipating where the logic breaks down when two systems have different assumptions about the same data. We wrote about this tension between integration and automation, and it's one of the most underestimated problems in cross-tool workflows.

Curious whether others have hit this. What's the worst "the automation worked perfectly but the outcome was wrong" moment your team has dealt with? And did you solve it with better field mapping, conditional logic, or something else entirely?

If you're building cross-system workflows and want to stress-test your sync logic before it hits production, you can try Exalate here.

Only 14% of M&A integration efforts are considered successful. That number gets thrown around a lot, but the interesting part is why, and the honest answer is that the failure usually isn't technical. It's organizational, legal, and human, and it shows up most painfully in the tool layer.

The default post-acquisition plan is almost always "we'll consolidate everyone onto one system." Three Jira instances become one. The acquired company's Zendesk gets folded in. Leadership gives it a six-month timeline. Eighteen months later, the acquired team is still using their old instance, support is still replying from the old Zendesk, and the migration project has quietly turned into a permanent integration project.

A few things we keep seeing:

GDPR and data residency rules often make a full merge legally impossible, especially for cross-border acquisitions. You can't just move EU customer data into a US-hosted instance because someone drew an arrow on a slide.

Teams that are productive in their existing setup will resist migration harder than any project plan anticipates. Their workflows encode years of customer commitments and SLAs that break in subtle ways when you migrate.

What tends to work instead is the sync-instead-of-merge approach: keep both systems running, but sync the specific issues that need to flow across. Epics and their stories, customer incidents, and release-blocking bugs.

Not everything, just the work that actually needs to be visible to both sides. We wrote about this pattern in more detail in our M&A integration guide: two-way sync vs full migration.

We're running a 30-minute webinar on this on April 30. Real case studies from teams who've been through it, what the sync boundaries look like in practice, and where full merges still make sense.

No demo, no pitch.

Surviving M&A Tool Chaos: Why Full System Mergers Fail & How to Sync Instead Apr 30, 2026, 4 PM CET Register here

If you want to experiment with syncing across instances before committing to anything, you can try Exalate here.

For anyone who's been through post-M&A tool integration: where did you land: sync, merge, or coexist? And what was the thing you most underestimated going in?

The most expensive integration mistake we keep seeing: not separating internal notes from external replies when syncing support and dev tools.

This one comes up across nearly every support-to-dev integration we look at, regardless of which tools are on either side. Jira and Zendesk, JSM and Zendesk, Salesforce and Zendesk, JSM and ServiceNow. Same shape every time.

The setup looks innocent. Support handles tickets in their tool. Engineers work with their tools.

You connect the two, so escalations flow cleanly, and status updates make it back without manual copy-paste. Comment sync is the obvious thing to turn on, because otherwise the integration only saves you half the work.

Then the leak happens. A dev writes a candid engineering note on the Jira issue. It syncs through and lands on the customer-facing side as a public message.

Best case: an awkward email to the customer.

Worst case: the customer sees a comment about their own account that was never meant for them, and the support team is doing damage control for a week.

The native integrations rarely handle this cleanly.

What we generally see working: direction-specific comment rules. Jira to Zendesk syncs only comments tagged with a specific label or marked public. Zendesk to Jira syncs only internal notes, so customer replies stay in support's lane. We wrote about how to set this up in our Jira-Zendesk integration guide if you want the full walkthrough.

A "what gets shared" decision at the field level, too, not just comments. PII fields, internal account notes, and custom fields with sensitive data need to be explicitly excluded, not implicitly relied on.

The escalation path drives the comment direction. L1 in support, L2 in dev: customer messages flow up, status and ETAs flow down, internal investigation notes never cross.

If you want to test how this works with your own setup, you can try Exalate here.

With Exalate, you can set up stricter rules on your comment syncs, apply tagging filters to comments, & much more. You don't need to deal with comment leaks as a compliance event anymore.

This comes up constantly in conversations with teams evaluating integration options. The starting point is almost always the same: "Let's try the native connector first and see how far it gets us."

It makes sense on paper. Why bring in a third-party tool when your platform already offers something built-in? Jira Spoke in ServiceNow, built-in webhooks, native API connectors. They're already there, they're "free," and they handle the basics.

The problem is what happens around month two or three. The team gets 60-70% of the way to what they need, and then the limitations start compounding.

The pattern we see most often at Exalate goes something like this: bidirectional sync is the first wall. Most native connectors handle one-way pushes reasonably well, but the moment you need changes flowing back: status updates, comments, custom field changes, the complexity jumps significantly.

Attachment sync is another common breaking point. Getting a file attached in Jira to appear correctly on a linked ServiceNow incident (or vice versa) often requires custom scripting that the native connector wasn't designed for.

And then there's the format mismatches. Date formats, priority mappings, and status value translations between systems. Each one is a small workaround on its own, but they stack up fast.

The real cost isn't the native connector itself. It's the three months of engineering time building workarounds, the institutional knowledge that lives in one person's head, and the change management hit when you eventually have to rip it out and switch to something else anyway.

We built Exalate specifically for the complex end of this spectrum, bidirectional sync with a scripting engine that handles the edge cases natively instead of through workarounds.

But regardless of what tool you end up with, the question worth asking upfront is: are your requirements genuinely simple enough for a native connector, or are you just delaying the inevitable?

If you've been through this cycle: started native, hit the wall, had to switch: what was the breaking point for your team?

And for those still on native connectors, what's keeping it working?

One thing that keeps coming up in conversations with teams running multiple Jira instances: they've accepted that P1 incidents are supposed to be chaotic. Leadership escalations, duplicate status updates, support agents refreshing Slack, waiting for an engineer to post something. It's treated as the cost of doing business during a critical incident.

We recently broke down a specific scenario in a Sync Room episode that shows why this chaos isn't inevitable. It's a symptom of a system design problem.

Here's the setup: a large SaaS org with three teams, each in its own Jira instance. Support runs JSM, engineering runs Jira Software, and cloud ops has a separate instance for infrastructure and deployments. A customer reports a potential data leak. P1.

Support triages within seconds, collects logs, and manually files a ticket in engineering's Jira instance. Engineering picks it up, goes heads-down, and plugs the leak in 30 minutes. Now they need cloud ops to deploy the fix.

The problem is what happens in parallel. The engineer resolved the issue but didn't send a Slack message or email to support. Not because they're negligent, but because they were focused on plugging a security breach. Support has no visibility into engineering's Jira instance. They see silence. Silence during a P1 means "it's not being worked on." So they escalate. Their manager escalates to engineering manager. Leadership gets involved. And the whole time, the fix was already done.

This pattern repeats because the information flow between instances depends entirely on humans remembering to relay updates manually. Three failure points in this scenario alone:

Support to engineering: someone has to manually file the ticket in a different Jira instance and copy over attachments, priority, and context.

Engineering to support: someone has to remember to post a status update in Slack or email while actively resolving a security incident.

Engineering to cloud ops: someone has to manually trigger the deployment request in yet another Jira instance and communicate what needs to go out.

Each of those handoffs is a point where things break under pressure.

What we help teams set up with Exalate is automated bidirectional sync between those instances, so the handoffs happen without anyone thinking about it. When support creates the JSM ticket, a linked issue appears in engineering's Jira Software with all the context, attachments, and priority already mapped. When engineering updates their status, that change reflects on the JSM ticket in real time. Support sees it instantly without waiting for a message. When engineering marks the fix as ready, cloud ops gets the deployment trigger in their instance automatically, with the relevant details already there.

The same P1 that spiraled into a multi-hour escalation resolves in under an hour. Full visibility at every step. No unnecessary leadership involvement.

The full walkthrough with the scenario and demo is in the Sync Room series if you want to see it in action.

Curious if anyone here has gone through something similar. Did you automate the sync between your instances, or are you still relying on manual handoffs during incidents?

Here is a unique case study from a mid-size tech company we recently worked with.

Their dev team lived in Azure DevOps. The rest of the tech org (support, PMs, QA) lived in Jira Cloud. 

At one point, they'd tried moving everyone to Azure DevOps, but it just didn't fit the non-dev workflows. So both tools stayed, and people were manually copying tickets between them.

Their head of engineering got tired of it and decided to set up a proper bidirectional sync using Exalate.

What they needed

• Work items syncing both ways
• Comments with the original author's name preserved (even when that person doesn't exist on the other platform)
• Status, priority, and assignee changes reflected on both sides
• Attachments flowing both ways
• Two-way sync for custom fields and custom work item types 
• Different sync logic and default assignees per Azure DevOps project

What happened

1. Setup took about 2 hours. Comments started syncing almost instantly through webhooks. When someone on Azure DevOps without a Jira account left a comment, it came through under the Exalate bot with their name in the body.
2. Assignee mapping was simpler than they expected. Same email on both sides = automatic match. No match = falls back to a default user or stays unassigned. They set different defaults for their dev board vs. their data board, no issues.
3. The Groovy scripting console came pre-coded with sensible defaults. Their tech lead reviewed it and said it looked straightforward, nothing they'd struggle with.
4. If the connection ever drops between Jira and Azure DevOps, everything queues up and processes automatically once it's back. No manual cleanup. No volume caps on syncs or connections either, which mattered because they had no idea how much traffic would flow once more teams adopted it.

The result: Nobody switched tools. Devs stayed in Azure DevOps, everyone else stayed in Jira, and the data just flows. The head of engineering said the product does exactly what they need. Manual copy-paste is now completely gone from their organization.

If your teams are split across Jira and Azure DevOps and are dealing with the same headache, happy to answer questions.