Federated ITSM: How to Make Multiple Service Desks Actually Work Together

Most enterprises have run an ITSM standardization project at least once. Most are still running two or three tools anyway.

We’ve seen this project in a lot of different companies. Leadership decides the organization needs to standardize on a single ITSM platform. The management approves the budget, a rollout plan gets built and a go-live date gets set.

A few months into the single ITSM platform, the picture gets repeated: the dev team is still in Jira, the support team is still in Zendesk, and the ServiceNow instance that was supposed to be the one true service desk is running for IT ops and nobody else.

The consolidation project is technically complete. The org has three ITSM tools.

This is federated ITSM, whether you planned for it or not.

Why the consolidation never fully lands

The mandate usually comes from the right place. Visibility, reporting, cost control. One platform means one dataset, one SLA view, one renewal conversation.

What it underestimates is that different teams have built their work around different tools for good reasons.

Dev teams using Azure DevOps or Jira have years of workflow automation, sprint board configuration, and backlog structure tied to those tools. Asking them to move to ServiceNow mid-project is like asking them to rebuild their entire workflow, not just a change in tooling.

In more than a few calls, the phrase that comes up is: “I never want to use Jira.” That’s not resistance to change. That’s a team that’s built their work around a different environment and can’t afford to stop what they’re doing to re-learn it.

The same applies to the other way.

IT ops teams running ServiceNow have CMDB records, catalog items, assignment groups, and approval workflows that don’t translate cleanly to Jira Service Management. The migration isn’t a lift-and-shift. It’s a rebuild.

So the consolidation project usually lands somewhere in the middle. Some teams move. Others don’t. A few move and then revert. And the org ends up with a federated setup it didn’t plan for, with no real structure to make it work.

What federated ITSM actually looks like

“Federated ITSM” sounds strategic. In practice, it usually looks like this: ServiceNow handles IT infrastructure and major incidents. Jira Service Management handles software-related requests and dev escalations. Zendesk or Freshdesk handles customer-facing support. Azure DevOps handles everything the dev team refuses to move out of.

Each tool works well for the team using it. The problems start at the boundaries.

A customer-reported incident in Zendesk needs investigation by the dev team in Jira. By the time the ticket crosses the boundary (usually via email or Slack, because there’s no structured connection), context is already missing. The original error details, the customer impact notes, and the priority the support team assigned. The dev team receives a summary and has to ask follow-up questions even before they can start.

Or an IT incident in ServiceNow turns out to require a code fix. The ServiceNow team closes the incident as “escalated to development.” The Jira ticket gets created manually. The ServiceNow team has no visibility into when the fix ships, so they email someone every few days to ask for an update. The dev team is annoyed. The ServiceNow team is in the dark.

These aren’t just edge cases. They’re the standard operating pattern in most federated ITSM environments.

The visibility problem

The reason most federated setups feel broken isn’t the tools. It’s that there’s no structured way for context to cross the boundary between them.

When you force consolidation, you solve the visibility problem by putting everyone in the same tool. That works if everyone actually moves. When they don’t (and they often don’t), you’ve just added friction without solving the underlying issue.

What actually works in practice is a sync layer between the tools each team is already using. Not a migration or a mandate, just a structured connection where a ticket created in one system can be seen, updated, and tracked from the other, without either team having to log in somewhere they don’t normally work.

This is where purpose-built sync tools like Exalate fit. You can set up a bidirectional sync between ServiceNow and Jira, or Jira and Zendesk, so that a ticket created by the support team is visible to the dev team in their environment, with the fields mapped to something that makes sense in context. Status updates flow both ways. Comments are shared. Neither team has to leave their tool or copy anything manually.

You can set up a similar connection between Jira and ServiceNow, or across multiple Jira instances if your org runs more than one. The setup takes days rather than months, and the teams keep working the way they already work.

The consolidation project might still happen eventually. But it doesn’t have to happen before your teams can see each other’s work.

Before the next consolidation conversation

If you’re heading into a conversation about ITSM standardization, or you’re the one being asked to run the project, a few things are worth establishing upfront.

Which teams are genuinely moveable, and which ones will create more disruption than the migration is worth? A dev team mid-sprint who’ve built their entire workflow in Jira is not a good migration candidate right now. An IT ops team on an aging on-prem tool with a contract expiring in three months is.

What does visibility actually require? In most cases, leadership wants a single reporting layer, not a single tool. Those are solvable problems independently. You can build cross-tool reporting from a sync layer without forcing everyone onto the same platform.

What happens at the boundaries? Before the project kicks off, map the actual workflows that cross tool boundaries: incidents that need dev fixes, support tickets that need infrastructure changes, service requests that involve multiple teams. These are the places where the federated setup will either work or break. Design those connections before you start the migration, not after.

Federated ITSM is less a philosophy than a practical reality for most enterprises above a certain size. The question isn’t whether you’ll end up with multiple tools. The question is whether you’ve structured the connections between them well enough that your teams can actually see each other’s work.

For more on how cross-tool sync works in ITSM environments, Exalate’s ITSM integration guide covers the main patterns. You can explore Exalate directly here.