A practical guide for IT service managers, DevOps leads, and enterprise architects evaluating Jira BMC Remedy integration options.

‍

Two Platforms, One Persistent Problem

BMC Remedy has been the backbone of enterprise ITSM for decades. Jira has become the default project and issue tracking tool for development and DevOps teams globally. In most mid-to-large enterprises, both are deeply embedded, and both are highly customized.

The problem is familiar: your ITSM team logs an incident in Remedy. It needs developer attention. Someone copies the key details into a Jira ticket, or sends a Slack message, or files are quest that gets picked up hours later with missing context. The developer resolves the issue. The Remedy incident stays open because no one updated it. A customer calls to ask for a status update, and the service desk agent has no idea the fix shipped yesterday.

A well-configured Jira BMC Remedy integration eliminates this loop entirely. But getting the integration right requires more than picking the first connector that appears in a search. The tool you choose determines how the integration holds up after a BMC upgrade, how it handles your custom fields, and whether your security team will find a third-party database full of copied incident data during their next audit.

This article covers what to look for, what tends to go wrong, and the questions worth asking before you commit to any approach. The full step-by-step technical setup guide lives in the ZigiOps documentation.

‍

Why Jira and BMC Remedy End Up in the Same Enterprise

BMC Remedy is purpose-built for ITIL-aligned service management. It handles incidents, problems, change requests, work orders, service catalog items, and asset management within a structured, governed framework that enterprise compliance teams trust. It is also, in most deployments, deeply configured: custom workflows, custom approval chains, custom priority scales, and CMDB relationships that have been tuned over years.

Jira was built for a different world: agile development, sprint planning, backlog management, and issue tracking at development velocity. It is flexible, heavily extensible, and the tool most development teams default to because it fits how they work.

According to BMC's positioning in the Gartner Magic Quadrant for ITSM, BMC Helix ITSM (the current evolution of BMC Remedy) is consistently rated as a Leader for enterprise-scale ITSM. Jira holds a parallel position in agile project management. Organizations run both because each is genuinely the best tool for its domain, not because anyone planned a two-platform architecture.

The integration requirement arises naturally from this. When a Remedy incident requires a code fix, someone has to get that context into Jira. When a developer closes a Jira issue, someone has to update the corresponding Remedy record. Without automation, those handoffs are manual, error-prone, and slow.

‍

What a Production-Grade Jira BMC Remedy Integration Actually Needs to Cover

Before evaluating tools, it is worth being explicit about what the integration needs to do in a real enterprise environment. The minimum viable version (incident in Remedy triggers a task in Jira) is straightforward. The production version is more demanding.

Bidirectional synchronization across the full record lifecycle

Creating a Jira task from a Remedy incident is the easy part. The harder part is keeping both records synchronized throughout their lifecycle: status changes, priority updates, comments, work notes, attachments, and resolution details flowing in both directions in real time. Without full lifecycle sync, the two records diverge. The developer marks the Jira issue resolved. The Remedy incident stays open for three more days. SLA timers keep running.

Support for all relevant entity pairs

The most common synchronization scenarios in a Jira BMC Remedy integration include:

•      Remedy Incidents to Jira Issues or Tasks

•      Remedy Problems to Jira Bugs

•      Remedy Change Requests to Jira Tasks or Epics

•      Remedy Work Orders to Jira Tasks

•      Jira Issues back to Remedy Incidents or Problems (reverse flow)

Not every organization needs every combination, but the platform needs to support all of them so the scope can expand without requiring a new tool.

Custom field handling for both systems

BMC Remedy deployments in enterprise environments carry years of custom configuration: custom ticket categories, custom priority definitions, custom approval workflow states, and CMDB-linked fields that do not exist in any standard schema. Jira projects carry custom issue types, custom fields, and custom workflow states that vary by team and project.

An integration that maps only standard fields leaves a significant portion of the actual operational data unsynced. The teams filling those gaps with manual workarounds are the same teams the integration was supposed to free from manual work.

Precise trigger conditions

Not every Remedy incident needs a Jira task. Not every Jira issue needs to create a Remedy record. Trigger conditions based on priority level, incident category, assignment group, work order type, or any other field value are what separate an integration that is useful from one that floods both systems with irrelevant records and destroys signal-to-noise ratio for both teams.

‍

Four Pitfalls That Cause Jira BMC Remedy Integrations to Need Rebuilding

Pitfall 1: Choosing a Homegrown Integration for a Complex Environment

Custom-coded integrations between Jira and BMC Remedy are built regularly by internal development teams. The appeal is control: a custom integration can be written to exactly match the current state of both systems, with no platform limitations.

The problem appears over time. BMC Remedy (now BMC Helix) releases regular platform updates. Jira Cloud releases continuously. Each update can change API endpoints, field names, authentication mechanisms, or introduce new mandatory fields. A custom integration that worked cleanly at build time requires ongoing maintenance after every update to either system.

That maintenance burden is rarely budgeted accurately upfront. The developer who built the integration often moves to another team or leaves the organization. Institutional knowledge thins. The integration starts producing silent failures: records that should sync, do not. Comments that should appear in both systems, appear in one. SLA data that should be current, is hours out of date.

What to do instead: Evaluate the total cost of ownership over three years, not just the initial build cost. A purpose-built integration platform with a defined upgrade path and vendor-managed API compatibility will cost less to maintain over time than a custom integration that requires developer attention after every platform release.

Pitfall 2: Using a Connector That Only Syncs in One Direction

Many lightweight connectors for Jira and BMC Remedy support incident creation in one direction: a Remedy incident creates a Jira task. What they do not support is the return flow: Jira task status changes updating the Remedy incident, developer comments appearing in Remedy work notes, or resolution details closing the original incident automatically.

One-directional sync creates a situation where the ITSM team's system of record is always behind. They have to check Jira manually, or ask the development team for status updates, or wait for someone to remember to update the Remedy ticket. The manual work the integration was supposed to eliminate simply moves to a different point in the workflow.

What to do instead: Confirm explicitly before selecting a tool that bidirectional sync covers comments, work notes, attachments, and status transitions, not just the initial record creation. Ask for a live demonstration of a Jira issue status change updating the corresponding Remedy incident. If the vendor cannot demonstrate this cleanly, it is not a production-grade integration.

Pitfall 3: Overlooking Data Storage and Security Architecture

Remedy records frequently contain sensitive operational data: incident descriptions with customer information, change request details with infrastructure specifics, work notes with internal diagnostic content. When an integration platform processes this data, the question of where it goes during transit matters.

A number of integration platforms operate by pulling data from the source system, storing it in an intermediate database or cloud environment, and then writing it to the target. This intermediate storage is often not documented clearly in marketing materials. It surfaces during security assessments or compliance audits, at which point it becomes a remediation problem rather than an evaluation criterion.

For organizations in regulated industries, or any organization with a mature information security posture, the integration vendor's data handling architecture needs to be evaluated the same way any other third-party data processor would be.

What to do instead: Ask any vendor explicitly: does your platform store any of the data it processes during transfer? A zero-data-storage architecture, where data is extracted from the source, processed in memory, delivered to the target, and nothing is retained, is the appropriate standard for enterprise environments. Ask for written documentation of the data handling architecture.

Pitfall 4: Not Scoping Trigger Conditions Before Configuration

Teams that skip the scoping conversation and go directly to configuration often end up with an integration that syncs too broadly. Every Remedy incident creates a Jira task. Jira developers receive notifications for incidents that have nothing to do with code. The Jira backlog fills with ITSM noise. Developers start ignoring integration-generated tickets. The integration becomes a liability.

The mirror image also happens: trigger conditions scoped too narrowly miss the incidents that actually require developer attention, and the manual handoff continues alongside the integration, which now creates its own overhead.

What to do instead: Hold a scoping session with ITSM team leads and development leads before any configuration begins. Define: which Remedy record types should trigger Jira records, what threshold conditions apply (priority level, category, assignment group), which Jira record types should update Remedy records, and what should explicitly never sync. Document this as a requirement before opening a configuration UI.

‍

‍

What to Look for When Choosing a Jira BMC Remedy Integration Tool

These criteria apply regardless of which vendor or approach you are evaluating. They are sequenced by how consequential each is if it turns out to be a gap in the tool you select.

‍

‍

‍

The Three Approaches to Jira BMC Remedy Integration

Native or marketplace connectors

Both Atlassian and BMC have marketplace ecosystems. Native connectors and marketplace plugins are fast to install and appear low-cost at the point of evaluation. Their limitations appear in production: they typically support standard fields only, bidirectional sync is often partial or requires additional configuration, and they are affected by upgrades to whichever system they are installed inside.

Appropriate for: simple, low-volume scenarios with standard fields and no complex workflow requirements. Not recommended for enterprise environments with custom Remedy configurations or regulated data requirements.

Custom-coded integration

Custom integrations built on the Jira and BMC Remedy REST APIs offer maximum flexibility at build time. The trade-off is ongoing maintenance cost. Both platforms release regular updates, and every update is a potential breaking change for a hardcoded integration. Custom integrations also lack built-in monitoring and alerting, meaning failures can be silent until they affect an SLA or surface in an audit.

Appropriate for: specific edge cases no existing platform handles, or short-term bridge integrations with a defined end date. Not recommended for ongoing production integrations between two actively maintained enterprise platforms.

Standalone no-code integration platform

A standalone platform operates entirely outside both Jira and BMC Remedy, connecting to each via their official APIs without installing anything inside either system. Configuration is handled through a UI, with no scripting required. The platform manages API compatibility updates independently of either system's release cycle, and changes to either platform's schema are detected and surfaced automatically.

This is the approach that scales reliably over time for enterprise environments. The quality gap between platforms in this category is significant, which is why the evaluation criteria above matter.

‍

How ZigiOps Addresses Each Evaluation Criterion

ZigiOps is a 100% code-free, standalone integration platform built for enterprise IT operations environments. It connects to BMC Remedy and Jira via their official APIs, operates entirely outside both systems, and requires no installation or changes inside either platform.

•      Zero data storage: ZigiOps processes all data in memory during transfer operations. No incident data, change request content, comments, or attachments are stored on ZigiOps servers at any point. The platform is ISO 27001 certified, confirming this architecture has been independently audited.

•      Standalone architecture: Nothing is installed inside BMC Remedy or Jira. ZigiOps operates as an independent application. Upgrades to either platform do not require changes to the integration configuration and do not cause integration downtime.

•      Full bidirectional sync: ZigiOps supports bidirectional synchronization across all supported entity types, including incidents, problems, change requests, and work orders. Status changes, comments, work notes, attachments, and all custom fields sync in both directions in real time.

•      Full entity coverage: Pre-built templates cover the most common Remedy-to-Jira entity pairs: Remedy Incidents to Jira Tasks, Remedy Problems to Jira Bugs, Remedy Change Requests to Jira Tasks, and Remedy Work Orders to Jira Tasks, as well as the reverse flows. Templates are fully customizable and serve as a starting point rather than a fixed configuration.

•      Dynamic schema loading: ZigiOps loads the complete schema of both systems at connection time, including all custom fields, custom entity types, and custom workflow states. Every field is available for mapping through the guided UI without scripting. Schema changes in either system are detected automatically.

•      Configurable trigger conditions: Trigger conditions in ZigiOps can be based on any field in either system, combined with AND/OR logic, and adjusted at any time through the UI. Only the records that meet the defined criteria sync, keeping both systems free of irrelevant noise.

•      Deployment flexibility: ZigiOps supports BMC Remedy on-premises and cloud deployments, and Jira Cloud, Jira Software Server, and Jira Data Center. Hybrid scenarios (on-premises Remedy with cloud Jira, or vice versa) are fully supported.

•      Unlimited transactions: ZigiOps does not impose transaction volume caps or per-record pricing. High-volume environments processing large numbers of daily incidents and work orders can run ZigiOps without throttling or volume-based cost escalation.

Explore the full integration capabilities on the Jira BMC Remedy integration page. See all supported Jira integrations on the Jira integrations page and all supported BMC Remedy integrations on the BMC Remedy integrations page.

‍

‍

What to Align on Before You Start Configuring

The most common cause of post-deployment rework in a Jira BMC Remedy integration is not technical. It is scope that was not defined before configuration began. A short alignment session between ITSM leads and development leads, documented before anyone opens a configuration UI, prevents the majority of the integration problems teams encounter in the first three months.

Work through these questions with both teams before you start:

•      Which Remedy entity types should trigger records in Jira? Incidents only, or also problems, change requests, and work orders?

•      What are the trigger conditions? Which priority levels, categories, or assignment groups qualify? Define the threshold explicitly.

•      Which Jira record types should update Remedy records on the return flow? All issues, or only specific types or labels?

•      Which fields are required in the Jira record for the development team to act without asking follow-up questions? Those are the fields the integration must populate.

•      Should work notes and comments sync bidirectionally, or only in one direction? Should all comments sync or only those explicitly flagged for cross-system sharing?

•      Which system is authoritative for each field type if both systems update the same field simultaneously?

•      What should explicitly never sync? Internal approval notes, confidential CMDB data, test records, and security-sensitive fields are common exclusions.

Answers to these questions define the integration scope. The scope drives the configuration. Configuration in ZigiOps typically takes a few hours to a day for a standard set of entity pairs, once scope is clear.

‍

See How ZigiOps Handles Your Specific Remedy and Jira Environment

The most reliable way to validate whether ZigiOps covers your specific Jira BMC Remedy integration requirements is to see it running against your actual Remedy configuration and your actual Jira projects, including your custom fields, your entity types, and your workflow states.

Book a demo and the ZigiWave team will walk through your specific scenario in a live environment. Or start a cloud trial and configure the integration yourself without any installation required.

‍