How to Integrate Jira with Azure DevOps: Mapping Work Items, Sprints and Statuses Across Two Agile Tools
Last updated: November 2026
To integrate Jira with Azure DevOps, you connect both tools through an integration layer, decide which Jira issue types correspond to which Azure DevOps work item types, align sprints with iterations, map statuses to states, and store a reference ID on both sides so updates and comments sync without duplicates. The hard part is not the connection itself but the mapping, because Jira and Azure DevOps model agile work differently. This guide gives you mapping tables you can adapt for your own Jira Azure DevOps integration, whether you configure them in a no-code platform such as ZigiOps, the integration platform by ZigiWave, or in custom code.
It is increasingly common for one organization to run both tools. Product managers and business teams plan in Jira, while engineering teams build, test and deploy in Azure DevOps because of Azure Repos, Azure Pipelines and close ties to the Microsoft stack. Mergers, outsourced development partners and platform teams that standardized years ago all add to the mix.
When the two tools are disconnected, someone becomes a human integration: copying stories, chasing status updates and reconciling two versions of the same backlog before every planning meeting. Connecting Jira and Azure DevOps removes that work, but only if the mapping reflects how both teams actually work.
Sync or migrate? Decide first
Before mapping anything, confirm what you need. Teams searching for "Jira Azure" solutions often mean one of two very different things:
- Ongoing sync: both tools stay in use, and selected work items are kept in sync continuously. This is what this guide covers.
- Migration: one tool is being retired, and history needs to move once, for example when you migrate Azure DevOps to Jira or the reverse.
Migration is a one-time project with its own concerns (history, attachments, users, links). Sync is an ongoing process where conflict handling, triggers and maintenance matter more. Some tools do both; many are designed for one. Knowing which you need prevents choosing the wrong approach.
Understand the two data models
Jira and Azure DevOps both support agile work, but their models differ in ways that affect every mapping decision.
Work item hierarchy
Jira's default hierarchy is Epic, then Story, Task or Bug, then Sub-task. Jira Premium and Enterprise plans can add levels above Epic. Azure DevOps hierarchies depend on the process template. In the Agile process, the default is Epic, then Feature, then User Story, then Task, with Bugs configurable to appear as requirements or tasks. Scrum uses Product Backlog Item instead of User Story, and Basic uses Issue.
The extra Feature level in Azure DevOps is the main source of confusion. You need a rule for where Jira epics land and what happens to Azure DevOps features in Jira.
Fields
Some fields map cleanly: Jira summary to System.Title, description to System.Description, assignee to System.AssignedTo. Others need decisions. Jira story points usually map to Microsoft.VSTS.Scheduling.StoryPoints in the Agile process, but to Microsoft.VSTS.Scheduling.Effort in Scrum. Jira components and labels have no single equivalent; teams often map components to area paths (System.AreaPath) and labels to tags (System.Tags).
Workflow
Jira workflows are fully customizable per project. Azure DevOps work item types have states grouped into fixed categories: Proposed, In Progress, Resolved, Completed and Removed. Mapping by category, rather than by name, keeps the integration stable when someone adds a new status.
Mapping work item types
Start with a type mapping table. The example below assumes the Azure DevOps Agile process and a standard Jira software project.
| Jira issue type | Azure DevOps work item type | Notes |
|---|---|---|
| Epic | Feature (or Epic) | Map to Feature if Azure DevOps Epics represent larger initiatives above Jira's scope |
| Story | User Story | Use Product Backlog Item for the Scrum process |
| Bug | Bug | Check whether bugs are managed as requirements or tasks in your team settings |
| Task | Task or User Story | Jira tasks are often backlog items; Azure DevOps tasks are usually child work under a story |
| Sub-task | Task | Keep the parent link so the task appears under the right story |
Two rules help keep this sustainable. First, only sync the types both teams actually need. Many integrations sync stories and bugs only, and leave tasks local to each team. Second, preserve parent links in both directions. A story that arrives in Azure DevOps without its parent feature is hard to plan around.
How this works in ZigiOps
In ZigiOps, the type mapping becomes conditions inside one integration: Jira stories create User Stories, bugs create Bugs, and conditional mapping chooses the target work item type for anything else. Because ZigiOps syncs related records along with the main record, the parent reference can travel with each item so it lands under the right feature.
Aligning sprints and iterations
Jira sprints and Azure DevOps iterations both represent time boxes, but they are structured differently. Jira sprints belong to a board and are created as needed. Azure DevOps iterations are defined as an iteration path tree (System.IterationPath) at the project level and selected per team.
You have three practical options:
- Do not sync sprints. Each team plans its own time boxes. This is the simplest option and often the right one when product and engineering plan on different cadences.
- Map sprint names to iteration paths. Create matching iterations in Azure DevOps, using a naming convention such as "Project\Sprint 42", and map Jira sprint names to them. This works when both teams share a cadence.
- Sync in one direction only. Engineering's Azure DevOps iteration is written to a read-only text field in Jira, so product managers can see when work is planned without changing it.
Option 3 is a good compromise for most hybrid teams. It gives visibility without two teams fighting over the same planning field. In ZigiOps, this is simply a one-way field mapping in the Azure DevOps to Jira update operation.
Mapping statuses to states
Status mapping is where most Jira Azure DevOps integrations break. Map statuses to states using categories, and decide what happens for states with no counterpart.
| Jira status | Jira category | Azure DevOps state | Azure DevOps category |
|---|---|---|---|
| To Do / Backlog | To Do | New | Proposed |
| Ready for Development | To Do | New (with a tag) | Proposed |
| In Progress | In Progress | Active | In Progress |
| In Review / In QA | In Progress | Resolved | Resolved |
| Done | Done | Closed | Completed |
| Won't Do | Done | Removed | Removed |
Keep in mind that Jira transitions may require screens or mandatory fields. If moving an issue to Done requires a resolution field, the integration has to set it, or the transition fails silently. Similarly, Azure DevOps rules may require a reason when changing state. Test every transition, not just the happy path.
ZigiOps handles this with conditional mapping in the UI: each Jira status maps to an Azure DevOps state, and a final fallback condition covers anything unexpected. Values a transition requires, such as a resolution or a reason, can be set in the same mapping, so transitions do not fail silently.
Comments, attachments and links
Beyond fields and states, decide how the conversation travels:
- Comments: Jira comments and the Azure DevOps Discussion (System.History) usually sync both ways. Ignore comments made by the integration user to prevent loops, and consider prefixing synced comments with the source system and author name, since the integration account posts them.
- Attachments: sync them if developers rely on screenshots and logs. Check size limits on both sides and decide how to handle files above the lower limit.
- Links: Azure DevOps links work items to commits, pull requests and builds. You usually cannot sync these as native links into Jira, but you can write the latest build or pull request reference into a Jira text field so product owners see progress.
ZigiOps synchronizes comments and attachments as related records of the main work item, in both directions, based on the mapping you configure.
Step-by-step: setting up a Jira Azure DevOps integration
Whatever tool you use, the setup follows the same sequence:
- Create integration accounts. Use a dedicated Atlassian account and a dedicated Azure DevOps account, not personal ones. In Azure DevOps, a personal access token with work item read and write scope is the usual authentication method; plan for its expiry date.
- Add correlation fields. Create a custom text field in Jira for the Azure DevOps work item ID, and a custom field in the Azure DevOps process for the Jira key. Inherited processes are required to add custom fields.
- Define the trigger. For example, Jira issues in project PROD with label "engineering" create User Stories in a specific Azure DevOps project and area path.
- Configure field mapping. Start with title, description, type, priority, story points and status. Add more only when someone needs them.
- Configure update flows in both directions, with filters to ignore changes made by the integration account.
- Test in a sandbox project on both sides, including reopen, deletion, re-parenting and attachments.
- Go live with a small scope, such as one team or one project, then expand.
In ZigiOps, these steps follow its guided UI: connect each system and run Test Connection, select the integrated entities, set trigger filters and field mappings, and let ZigiOps store the correlation IDs and ignore its own updates so nothing loops.
Choosing how to connect
There are several ways to integrate Jira with Azure DevOps. Atlassian offers an app that shows Azure DevOps development information in Jira, which is useful for linking commits and builds but is not a full work item sync. For real two-way synchronization, the main options are a standalone no-code platform such as ZigiOps, Marketplace apps such as Exalate or Getint, or a custom integration built on both REST APIs. ZigiOps is a standalone application that connects to both tools through their APIs, does not store the transferred data and can be deployed in the cloud or on-premises.
When comparing options, test them against your mapping tables: can the tool map Jira epics to Azure DevOps features, preserve parent links, handle different process templates, and support Azure DevOps Server on-premises if you still run it? A short proof of concept with your real project configuration is worth more than any feature list.
Common mistakes to avoid
- Syncing every issue type and every field "just in case", which multiplies conflicts.
- Mapping statuses by name instead of category, so a renamed status breaks the flow.
- Letting both teams edit the same planning fields, such as sprint or story points.
- Using a personal access token tied to an employee who later leaves.
- Ignoring process template differences between Azure DevOps projects in the same organization.
Keeping the integration healthy after go-live
Process templates and Jira workflows change over time. Someone adds a status, a new mandatory field or a new work item type, and the sync starts failing for a subset of items. Agree that changes to either configuration are reviewed by the integration owner first, and check the integration's error log weekly during the first months. A simple monthly report of items that exist on one side but have no correlation ID on the other catches drift early.
Frequently asked questions
How do I integrate Jira with Azure DevOps?
Connect both tools through an integration app, platform or custom API integration, map Jira issue types to Azure DevOps work item types, map statuses to states, and store a correlation ID on both sides. Then configure create and update flows and test them in a sandbox before going live.
Can Jira and Azure DevOps sync in both directions?
Yes. Most dedicated integration tools support two-way sync of fields, statuses, comments and attachments between Jira and Azure DevOps. Atlassian's own Azure DevOps app focuses on development information rather than full work item synchronization.
Can ZigiOps sync Jira and Azure DevOps in both directions?
Yes. ZigiOps syncs work items, statuses, comments and attachments between Jira and Azure DevOps in both directions, with type, status and priority mapping configured in a no-code UI.
How should Jira epics map to Azure DevOps?
Most teams map Jira epics to Azure DevOps features, because the Azure DevOps Agile process has an extra level (Epic, Feature, User Story). Map to Azure DevOps epics instead if your Jira epics represent large, multi-quarter initiatives.
Should I sync Jira sprints with Azure DevOps iterations?
Only if both teams share the same cadence. A common compromise is to sync the Azure DevOps iteration into a read-only Jira field, so product teams see planning without both sides editing it.
What is the difference between syncing and migrating Azure DevOps to Jira?
Syncing keeps both tools in use and updates selected work items continuously. Migrating moves data once, usually including history, so one tool can be retired. They need different tools and planning.
Where do story points go in Azure DevOps?
In the Agile process, story points map to Microsoft.VSTS.Scheduling.StoryPoints. In the Scrum process, the equivalent field is Microsoft.VSTS.Scheduling.Effort.
Key takeaways
- Decide whether you need ongoing sync or a one-time migration before choosing a tool.
- Map Jira epics, stories and bugs to Azure DevOps work item types based on your process template.
- Map statuses to states by category, and test every transition, including mandatory fields.
- Avoid syncing sprints both ways; one-way visibility is usually enough.
- Use dedicated integration accounts, correlation fields and a small pilot scope.
- A no-code platform such as ZigiOps lets you keep these mappings in a UI, so they are easy to adjust when either team changes its process.