How to Migrate from Azure DevOps to Jira: A Step-by-Step Guide (2026)

[#1]

Your team is moving from Azure DevOps to Jira; Maybe it is a merger, maybe leadership picked a new stack, maybe you are the Jira team that just inherited a pile of Azure DevOps work items.

Whatever got you here, this migration is well understood territory. The hard part is not moving the data. It is translating it, since Azure DevOps and Jira organize work in genuinely different ways.

TL;DR 

Your team is moving from Azure DevOps to Jira; Maybe it is a merger, maybe leadership picked a new stack, maybe you are the Jira team that just inherited a pile of Azure DevOps work items.

Whatever got you here, this migration is well understood territory. The hard part is not moving the data. It is translating it, since Azure DevOps and Jira organize work in genuinely different ways.

Here is the full walkthrough: what actually needs to move, how to map it, and where teams usually get tripped up.

What actually moves in an Azure DevOps to Jira migration?

Here is the thing about this migration: it is rarely just about titles and descriptions. Move only the bare fields and you have technically migrated something, but you have also thrown away most of the reason anyone keeps history in the first place.

A real migration covers work items and their full change history, comments and attachments, links between items such as parent-child and related-to relationships, iterations and area paths, epics and their child items, custom fields, and workflow status history.

None of this map one-to-one between Azure DevOps and Jira, so each piece needs its own decision. Azure DevOps work items become Jira issues. Iterations become sprints. Area paths usually turn into Jira components or a custom field, depending on how granular your team structure actually is.

Before mapping anything, spend an afternoon looking at how your Azure DevOps project is actually structured. That structure is what you are translating, not just the data sitting inside it.

Step 1: Audit your Azure DevOps data before you touch Jira

Do not start with a migration plan. Start with an inventory.

Run a work item query in Azure DevOps and get a real picture of what is in scope: every work item type, every custom field, how many work items and attachments you are actually dealing with. Flag anything custom, since it will not have an obvious Jira equivalent waiting for it. This is also your chance to catch problems while they are still cheap to fix, including broken links, work items missing required fields, and attachments that were deleted but are still referenced somewhere. Fix these in Azure DevOps. Fixing them after they have landed in Jira is a much worse afternoon.

Step 2: Map work item types, fields, and workflow states

Jira issue types depend on which project template you pick, whether that is a company-managed Scrum or Kanban project or a team-managed one. Here is a reasonable starting point, though your process template will probably need some adjusting on either side.

Feature is the one that trips people up. Jira does not have a default Feature issue type, so it either folds into Epic or becomes a custom issue type. Decide this before migration, not mid-migration.

Workflow states need the same treatment. Azure DevOps' Agile process moves through New, Active, Resolved, and Closed. Jira's default is To Do, In Progress, and Done. If your Azure DevOps workflow has custom states like In Review or Blocked, decide whether Jira gets a matching custom status or whether it just collapses into the closest built-in one. Same logic applies to custom fields: list each one in use in Azure DevOps and confirm Jira has somewhere for it to land. Fields without a target do not throw an error. They just quietly disappear.

Azure DevOps work item type (Agile process)	Jira issue type
Epic	Epic
Feature	Epic or a custom issue type
User Story	Story
Task	Task
Bug	Bug

Step 3: Map user identities between the two systems

Azure DevOps and Jira do not recognize the same identity as the same person. Azure DevOps ties everything to a Microsoft Entra ID identity. Jira Cloud uses its own internal account ID. Before migrating anything, build a mapping file connecting each Azure DevOps identity to the right Jira account, usually by email address. Skip this step and issues either lose their assignee and reporter entirely, or worse, get quietly attached to the wrong person, since name matching across two systems is nowhere near reliable enough to trust on its own.

Step 4: Choose a migration method

There are three general options here, and they trade off speed against fidelity.

CSV export and import is the fastest to set up, using a work item query exported from Azure DevOps and Jira's built-in importer. It leaves comments and attachments behind, and history is limited to whatever fields the query includes. Fine for a small backlog. Rough at real volume.

REST API scripting gives full control, since both platforms expose REST APIs for reading and writing work items and issues. Someone on the team needs to actually build and test this, including pagination, rate limits, and separate logic for links, attachments, and comment history. That is real developer time, not a weekend project.

Purpose-built migration tools like OpsHub Migration Manager (OMM), connect to both systems directly and handle field mapping, user identity mapping, and history preservation through an easy-to-use, no-code interface. This is usually the fastest route for teams without spare engineering time and no tolerance for downtime or disruption.

Step 5: Run a pilot migration before the full move

Migrate one project, or even just a slice of one, before touching everything else. This is where mapping problems show up, an unmapped custom field here, a broken link there, while they are still cheap to fix. Go through the migrated Jira issues against the originals field by field. Not a glance, a real comparison. Dates, history, and relationships all need to check out.

Step 6: Validate before cutover

Once the pilot looks right, validate the full migration in stages instead of all at once. Comment timestamps and authorship should be intact. Attachments should open. Links should point to the right issues. Sprint data should line up with the Jira boards. Work item counts on both sides should match before anyone calls it done.

Step 7: Plan the cutover

Pick an actual date. Stop creating new work in Azure DevOps and start using Jira exclusively from that point on. Tell every team involved, because a migration that runs alongside continued Azure DevOps use just creates two sources of truth, which is worse than one imperfect one. Keep the old Azure DevOps project around in a read-only or archived state for a while afterward, so the history is still there if anyone needs to check something, without the risk of new work quietly piling up in the wrong place.

What mistakes should you avoid?

• Leaning on CSV when comment history or attachments actually matter, since CSV just does not carry them.
• Leaving custom fields unmapped. This does not throw an error. It quietly loses data instead.
• Skipping user identity mapping, then finding out later that half the issues have the wrong assignee.
• Migrating everything in one shot instead of piloting first.
• Forgetting about links to work items outside the migration scope. Those references break after cutover if nobody accounted for them.

Refer to this Atlassian marketplace listing on Azure DevOps to Jira migration. 

Frequently Asked Questions (FAQs)

Q1) Can you migrate Azure DevOps work items to Jira without losing comment history?

Ans 1) Yes, but only with the right method. CSV export drops comments entirely. A REST API script or a purpose-built migration tool can preserve comment history, authorship, and timestamps if it is built to handle that data.

Q2) Does Azure DevOps Feature map to a specific Jira issue type?

Ans 2) Not directly. Jira does not have a default Feature issue type, so teams either map it to Epic or create a custom issue type before migration starts.

Q3) How do you handle user mapping between Azure DevOps and Jira?

Ans 3) Build a mapping file connecting each Azure DevOps Microsoft Entra ID identity to the matching Jira account, usually by email address, before running the migration.

Q4) How long does an Azure DevOps to Jira migration take?

Ans 4) It depends on the number of work items, how much history needs preserving, and whether the migration runs in phases. A phased approach with pilot validation is more predictable than migrating everything in one pass.

Q5) What is the safest way to test a migration approach before committing to it?

Ans 5) Run a pilot migration on a single project or a small subset of work items, then compare the result field by field against the original before scaling up.

Closing thought

This migration is less about moving data and more about deciding, deliberately, how your team's work is going to be represented somewhere new. Do the mapping work up front, validate in stages, and there is a lot less cleanup waiting after cutover. This kind of move usually comes up after a merger, a company standardizing on Atlassian, or a broader consolidation of tracking tools, and the same discipline applies no matter which of those brought you here.