Syncing Epics, Story Points and Parent Links Between Jira and Azure DevOps Without Breaking Your Hierarchy

Last updated: November 2026

To keep your hierarchy intact in a Jira Azure DevOps integration, first decide how Jira's Epic, Story and Sub-task levels line up with the Azure DevOps Epic, Feature, User Story and Task levels of your process template. Then sync parent links as a separate step after both records exist, map story points to the estimation field your process actually uses (Story Points, Effort or Size), and translate components and sprints into area paths and iteration paths with explicit tables. Most broken hierarchies come from skipping one of these decisions, not from the tool. In ZigiOps, the no-code integration platform by ZigiWave, each decision becomes a mapping rule in a guided UI.

Many organisations run Jira and Azure DevOps side by side. Product managers plan in Jira, engineering builds and ships in Azure DevOps, or two business units arrive at different tools after an acquisition. Syncing titles and statuses between them is easy. Keeping the structure is hard. After a few weeks, Features appear without parents, story points add up to different totals in each system, and sprint reports stop matching.

This guide focuses on the structural side of an Azure Jira integration: hierarchy levels, parent links, estimation fields, area paths and iteration paths. It applies whether you use Atlassian's Azure DevOps app, a third-party integration platform or a custom REST integration.

Why hierarchy is the hardest part of a Jira Azure DevOps integration

Field mapping is a one-to-one problem: field A in one system becomes field B in the other. Hierarchy is a graph problem. A work item's position depends on its parent, which depends on its own parent, and every link points at a record ID that only exists in one system.

Three structural differences cause most of the trouble:

• Different numbers of levels. Out of the box, Jira has Epic, a standard level (Story, Task, Bug) and Sub-task. Azure DevOps adds a Feature level between Epic and the requirement level.
• Different link models. Jira stores the parent on the child, in the parent field. Azure DevOps stores parent and child as hierarchy links on both items, and exposes the parent through System.Parent.
• Different estimation fields. Jira usually uses a story points field, while Azure DevOps uses a different field depending on the process template.

Step 1: Line up the hierarchy levels

Know your Azure DevOps process template

Azure DevOps ships with four system processes, and each names the backlog levels differently. Inherited processes can rename levels or add custom work item types, so check your organisation's process settings before designing any mapping.

Default backlog levels in Azure DevOps process templates

Process	Portfolio level 1	Portfolio level 2	Requirement level	Task level	Estimation field
Agile	Epic	Feature	User Story	Task	Story Points (Microsoft.VSTS.Scheduling.StoryPoints)
Scrum	Epic	Feature	Product Backlog Item	Task	Effort (Microsoft.VSTS.Scheduling.Effort)
CMMI	Epic	Feature	Requirement	Task	Size (Microsoft.VSTS.Scheduling.Size)
Basic	Epic	None	Issue	Task	Effort (Microsoft.VSTS.Scheduling.Effort)

Bugs need a separate decision. Each Azure DevOps team can choose to track bugs at the requirement level, at the task level or not on backlogs at all. Your mapping of Jira bugs has to follow that setting.

Know your Jira hierarchy

Standard Jira has three levels: Epic, the standard issue types (Story, Task, Bug and any custom types) and Sub-task. In Jira Cloud, the parent field links a standard issue to its epic and a sub-task to its parent issue, replacing the older Epic Link field. On some Jira plans, administrators can add custom levels above Epic, such as Initiative, using the hierarchy configuration that comes with advanced planning features.

Choose a level mapping

Because Azure DevOps has one more level than standard Jira, you have three practical options for the Feature level.

1. Map Jira Epic to Azure DevOps Feature. Azure DevOps Epics stay native to Azure DevOps and are not synced. This suits teams where Jira epics are deliverable-sized and Azure DevOps Epics are portfolio-level themes managed by engineering leadership.
2. Map Jira Epic to Azure DevOps Epic and skip Features. Stories link directly to Epics in Azure DevOps. This works but leaves Features empty and breaks Feature-level rollups that many Azure DevOps teams rely on.
3. Add a Jira level. If your Jira plan supports custom hierarchy levels, add a level above Epic (for example, Initiative) and map Initiative to Azure DevOps Epic and Jira Epic to Feature. This gives a full four-level match.

Example hierarchy mapping between Jira and Azure DevOps (Agile process)

Jira level	Azure DevOps level (option 1)	Azure DevOps level (option 3)	Sync direction
Initiative (custom level)	Not synced	Epic	Jira to Azure DevOps
Epic	Feature	Feature	Jira to Azure DevOps
Story	User Story	User Story	Both directions
Bug	Bug (requirement level)	Bug (requirement level)	Both directions
Sub-task	Task	Task	Both directions, or not synced

Many teams choose not to sync sub-tasks at all. Tasks are usually how engineers break down their own work, and syncing them adds volume without helping anyone on the Jira side.

Step 2: Sync parent links in the right order

The ordering problem

A parent link can only be created when both records exist in the target system. If a User Story syncs before its Feature, the integration has no target ID to link to. Depending on the tool, the link is either dropped silently or the whole create fails. This is the main reason hierarchies break.

Rule: create records first, link them second. There are two common ways to do this:

• Ordered sync. Sync from the top of the hierarchy down: Epics, then Features, then Stories, then Tasks. Before linking a child, look up the parent's correlation ID. If the parent has not synced yet, retry the link on the next cycle.
• Deferred linking. Create every record without a parent, then run a separate update step that sets parents once all correlation IDs exist. This is more forgiving when items are created out of order, for example in bulk imports.

How the link is written on each side

In Jira, the integration sets the parent field on the child issue to the key of the parent. In Azure DevOps, the integration adds a hierarchy link of type Parent (System.LinkTypes.Hierarchy-Reverse) from the child to the parent work item, and Azure DevOps creates the reverse Child link automatically. System.Parent then shows the parent's ID, but you write the link through the relations of the work item rather than by setting System.Parent directly.

Correlation IDs make linking possible

Every synced record needs the other system's ID stored on it. In Jira, use a dedicated custom text field such as "Azure DevOps ID". In Azure DevOps, use a custom field or a hyperlink relation to the Jira issue. The integration looks up these IDs whenever it needs to translate a parent reference.

How this works in ZigiOps: ZigiOps stores the ID of one record in a field of the other, for example the Azure DevOps work item ID in a Jira custom field, so it can keep updating the right pair in both directions. Use the ZigiOps documentation's recommendation of a dedicated custom field, so users and other automations do not overwrite it.

Edge cases for parent links

• Re-parenting. When a story moves to another epic in Jira, the integration must remove the old Parent link in Azure DevOps before adding the new one. Azure DevOps allows only one parent, and the add fails if the old link remains.
• Parent not in scope. If a child is synced but its parent is filtered out (for example, the epic belongs to a different Jira project), decide whether to sync the parent anyway, leave the child unparented, or link it to a placeholder Feature.
• Deleted parents. If a parent is deleted in one system, do not delete children in the other. Remove the link and flag the orphaned children for review.
• Cross-level links. Azure DevOps lets teams link a User Story directly to an Epic, skipping Features. If your mapping expects a Feature, those stories will not resolve to a Jira parent. Decide whether to map them to the epic or leave them unlinked.

Step 3: Map story points and estimation fields

Find the right field on each side

In company-managed Jira projects, estimates usually live in a custom field called Story Points. Team-managed projects use Story point estimate. Check the field ID your boards actually use, because some sites have both fields, and only one appears on the board.

In Azure DevOps, the field depends on the process: Story Points for Agile, Effort for Scrum and Basic, Size for CMMI. Inherited processes may add their own fields. The integration must write to the field the team's backlog and velocity charts read.

Decide who owns the estimate

Estimates are set during refinement or sprint planning, which happens in one tool. If both teams can edit the estimate, a change in one system will overwrite the other on the next sync, and you lose the history of why it changed.

Rule: the team that commits to the work owns the estimate. If engineering plans sprints in Azure DevOps, sync story points from Azure DevOps to Jira only. Product managers still see the numbers in Jira, but cannot change them there.

How this works in ZigiOps: once both systems are connected, ZigiOps loads their schemas, so Microsoft.VSTS.Scheduling.StoryPoints or Effort and the Jira story points field are selectable from dropdown lists. Map the estimate only in the ZigiOps update operation that runs from the owning system, and the other direction leaves it untouched.

Rollups do not sync

Azure DevOps can show rollup columns, such as the sum of story points under a Feature. Jira offers similar totals through plans and reports. These are calculated, not stored on the parent, so do not try to sync them. Sync the child estimates correctly and let each system calculate its own totals. If the totals differ, a child is missing or has the wrong parent.

Estimation field mapping between Jira and Azure DevOps

Jira field	Azure DevOps field	Process	Notes
Story Points (company-managed)	Microsoft.VSTS.Scheduling.StoryPoints	Agile	Direct numeric mapping
Story point estimate (team-managed)	Microsoft.VSTS.Scheduling.Effort	Scrum, Basic	Direct numeric mapping; confirm both teams use the same scale
Story Points	Microsoft.VSTS.Scheduling.Size	CMMI	Direct numeric mapping
Original estimate (time tracking)	Microsoft.VSTS.Scheduling.OriginalEstimate	All, on Tasks	Jira stores time in seconds via the API; Azure DevOps uses hours. Convert units
Remaining estimate	Microsoft.VSTS.Scheduling.RemainingWork	All, on Tasks	Convert units; usually synced one way only

A scale mismatch is a common hidden problem. If one team uses Fibonacci points and the other uses T-shirt sizes converted to numbers, the integration will copy numbers that mean different things. Agree a scale before you sync.

Step 4: Translate components and sprints into area and iteration paths

Components and area paths

Jira components group issues inside a project, and an issue can have several. Azure DevOps area paths (System.AreaPath) are a tree, and each work item has exactly one. Area paths also decide which team's backlog shows the item, so a wrong mapping means work disappears from a team's view.

Rule: map one Jira component to one area path, and decide what happens when an issue has several components. Common choices are to use the first component, to use a priority order, or to use a default area path and flag the item.

How this works in ZigiOps: conditional mapping in ZigiOps translates each component into an area path without scripts. Add a final fallback condition that sets a default area path, so items with an unexpected component still land somewhere visible.

Sprints and iteration paths

Jira sprints belong to a board and have start and end dates. Azure DevOps iteration paths (System.IterationPath) are a tree of iterations, each optionally with dates, and teams subscribe to the iterations they use. The names rarely match.

Rule: sync the sprint in one direction only, from the system where sprints are planned. Maintain a lookup table of sprint names to iteration paths, and create the matching iteration before the sprint starts. If no match exists, leave the field unchanged rather than failing the update.

Example component and sprint mapping

Jira value	Azure DevOps value	Rule
Component: Payments	Area path: Platform\Payments	One-to-one lookup
Component: Mobile, Web	Area path: Platform\Mobile	First component wins; flag for review
No component	Area path: Platform (team default)	Default value
Sprint: Platform Sprint 42	Iteration path: Platform\2026\Sprint 42	Lookup table maintained each quarter
Sprint: none (backlog)	Iteration path: Platform (root)	Root iteration means backlog

Sync versus migration

Some teams search for how to migrate Azure DevOps to Jira, or the reverse, when what they need is ongoing sync, and vice versa. The structural rules in this guide apply to both, but the order changes.

• Ongoing sync handles items created continuously, so deferred linking and retries matter most.
• One-time migration can be run strictly top-down: all Epics, then all Features, then all Stories, then links. Run a count check at each level before moving on.

Choosing a tool

Atlassian's Azure DevOps app for Jira links development activity to issues but is not designed for full work item sync. For two-way sync, ZigiOps is a standalone no-code platform that connects to both systems through their APIs. ZigiOps syncs fields, comments and attachments in both directions, uses conditional mapping for area paths and estimation fields, stores no transferred data and has no transaction limits between a pair of instances. Script-based or app-based alternatives include Exalate, Getint and OpsHub, and some teams build their own on the Jira and Azure DevOps REST APIs. Whichever you evaluate, check specifically how each handles parent links when items arrive out of order, re-parenting, and process-specific estimation fields. These are the areas where tools differ most.

Testing checklist

1. Create an Epic, two Stories and a Sub-task in Jira at the same time and confirm the full hierarchy appears in Azure DevOps.
2. Create a Story before its Epic and confirm the link is added once the Epic syncs.
3. Move a Story to another Epic and confirm the old Parent link is removed and the new one added.
4. Change story points in the owning system and confirm the other updates. Change them in the non-owning system and confirm nothing syncs back.
5. Compare the story point total under one Feature in Azure DevOps with the total under the matching Jira Epic.
6. Add an issue with two components and confirm the agreed area path rule.
7. Move an issue to the next sprint and confirm the iteration path updates.
8. Delete a parent in one system and confirm children are unlinked, not deleted.

Troubleshooting

Troubleshooting hierarchy and estimation sync

Symptom	Likely cause	Fix
Stories appear in Azure DevOps without a Feature	Child synced before parent; link dropped	Enable deferred linking or retry links on the next cycle
Error when moving a story to another epic	Old Parent link not removed; Azure DevOps allows one parent	Remove the existing hierarchy link before adding the new one
Story points empty in Azure DevOps	Mapped to Story Points on a Scrum or Basic process	Map to Effort, or to the field your process uses
Story points empty in Jira	Mapped to the wrong of two story point fields	Check which field the board uses
Items missing from a team's backlog	Wrong or default area path	Review the component to area path table
Sprint update fails	Iteration path does not exist yet	Create iterations in advance; skip unmatched values

Frequently asked questions

How do I sync Azure DevOps work items with Jira and keep the hierarchy?

Map hierarchy levels first, store correlation IDs on both sides, create records before linking them, and sync parent links as a separate step that retries when a parent is not yet available.

What is the Jira equivalent of an Azure DevOps Feature?

Standard Jira has no Feature level. Most teams map Jira Epics to Features, or add a custom level above Epic in Jira so that Epic maps to Feature and the new level maps to Azure DevOps Epic.

Which Azure DevOps field holds story points?

It depends on the process: Story Points (Microsoft.VSTS.Scheduling.StoryPoints) in Agile, Effort in Scrum and Basic, and Size in CMMI. Inherited processes may use custom fields.

Should story points sync both ways?

Usually not. Let the team that plans and commits to the work own the estimate, and sync it one way to the other system.

Can Jira sprints be synced with Azure DevOps iterations?

Yes, with a lookup table from sprint names to iteration paths. Sync in one direction, from the system where sprints are planned, and create iterations before the sprint starts.

Can ZigiOps sync Jira and Azure DevOps work items in both directions?

Yes. ZigiOps creates and updates Jira issues and Azure DevOps work items in both directions, including comments and attachments, and maps fields such as story points, area paths and states through its no-code UI.

Does the Jira Azure DevOps integration from Atlassian sync full work items?

Atlassian's app focuses on linking development information to Jira issues. For full two-way sync of work items, fields and hierarchy, teams use third-party tools or custom integrations.

Key takeaways

• Know your Azure DevOps process template: level names and estimation fields differ between Agile, Scrum, CMMI and Basic.
• Decide how the Feature level maps to Jira before configuring anything.
• Create records first and link them second, with retries for parents that have not synced yet.
• Handle re-parenting by removing the old Parent link before adding a new one.
• Let one team own story points, and let each system calculate its own rollups.
• Translate components and sprints into area and iteration paths with lookup tables and sensible defaults.
• ZigiOps turns these rules into no-code mappings, with correlation IDs, conditional mapping and one-way estimate ownership configured in its UI.