Moving from Azure DevOps to Jira is rarely an all-or-nothing decision. Many organizations want Jira for planning, portfolio visibility, and cross-team work. At the same time, their engineers are productive in Azure Repos and Azure Pipelines. Before you start an Azure DevOps to Jira migration, decide which of those problems you are actually solving.
This guide explains when to integrate the two platforms, when to migrate, and how to do either without losing data or momentum.
Azure DevOps to Jira: integrate or migrate?
Two patterns cover most situations.
- Integrate when engineering is happy with Azure Repos and Pipelines, but leaders and business teams need work tracked in Jira. Code stays in Azure DevOps, and development activity appears on Jira issues.
- Migrate when Azure Boards is the problem. Common signs include inconsistent processes, weak cross-project reporting, or a broader decision to standardize planning on Jira and Confluence. In that case, work items move and Azure Boards is retired for those teams.
A third, temporary pattern is also common: sync both systems during a transition. Atlassian’s own migration guidance notes that old and new systems may need to stay in sync for months. Plan for that cost early rather than discovering it late.
The integration option: Azure DevOps for Jira
Atlassian publishes a free Marketplace app, Azure DevOps for Jira, for Jira Cloud. It links branches, commits, and pull requests to Jira issues through issue keys. It also shows builds and deployments on the board and in the issue view. In addition, it adds deployment timelines and an insights panel for deployment frequency and cycle time.
The practical requirement is discipline. Developers must include the Jira issue key in branch names, commit messages, and pull request titles. A short working agreement and a pull request template usually solve this. With that in place, product owners see delivery status without asking engineers for updates.
Planning a full migration
When a full move is the right answer, the work falls into five phases.
- Define scope and rationale. Write down why you are moving and what success looks like. Then decide whether to move all history or only active projects.
- Inventory the current setup. Document projects, work item types, custom fields, area and iteration paths, states, permissions, and integrations such as Power BI or build triggers.
- Map data deliberately. Map User Story to Story, and align states such as New, Active, and Closed to Jira statuses. Build a user mapping file based on email addresses. Use the move to simplify workflows, not to copy every customization.
- Pilot, then move in small batches. First, migrate a non-critical project to a staging site. Validate field values, links, attachments, and parent-child hierarchy before you touch production.
- Back up and plan rollback. Take full backups before each wave. Also keep Azure DevOps available in read-only mode during the transition.
Choosing tools for an Azure DevOps to Jira move
For a simple move, the Jira Cloud CSV importer works. Atlassian’s documentation lists Azure DevOps among supported sources. You run a work item query, save the results to a spreadsheet, and import the CSV. However, CSV is best for flat data. History, attachments, and complex links usually call for a Marketplace app.
Apps such as TFS4JIRA and Exalate can migrate history and links, or keep both systems in sync during a transition. Evaluate each one on how it handles data, whether it stores your data, and the quality of vendor support. In regulated environments, those questions matter more than feature lists.
| Approach | Best for | Watch for |
|---|---|---|
| Azure DevOps for Jira app | Keeping code in Azure DevOps and planning in Jira | Issue key discipline in branches, commits, and pull requests |
| CSV import | Small, flat data sets and active work only | Attachments, comments, and links need extra handling |
| Migration or sync app | Large estates, history, and phased cutovers | Data handling, licensing, and support terms |
Identity, permissions, and change management
Migrations often fail on access, not data. If Azure DevOps already uses Microsoft Entra ID, connect Jira to the same identity source before go-live. As a result, user mapping and deprovisioning follow your existing controls. Our guide to Atlassian Guard and Entra ID covers provisioning, SSO, and SCIM. Recreate permissions by role rather than by individual, and review them with system owners.
Next, manage the change itself. Developers lose familiar screens, and report consumers need new dashboards. Train by role and publish a short guide that shows where each familiar item now lives. Then track adoption for the first few sprints.
How to measure success
- Data accuracy after validation, sampled by project
- Open migration defects at cutover
- Share of active users who sign in to Jira within two weeks
- Time to the first sprint completed in Jira
- Dashboard parity for the most used reports
Frequently asked questions
Can we keep code in Azure DevOps and plan in Jira?
Yes. Atlassian’s free Azure DevOps for Jira app links branches, commits, pull requests, builds, and deployments to Jira issues in Jira Cloud. Many teams keep repos and pipelines in Azure DevOps for the long term.
How long does a migration take?
It depends on the number of projects, the level of customization, and how much history you keep. A pilot project can often move in weeks. Larger estates usually move in waves, with a sync period between systems.
Should we migrate all historical work items?
Usually not. Move active work and recent history that teams still use. Then archive older data in a read-only export so it remains available for audits.
How VTPMO can help
VTPMO is a team of Atlassian platform specialists with Atlassian Certified Professionals. We are also a Microsoft Solution Provider, so we work on both sides of this move. We have supported Agile delivery on Atlassian tools for organizations such as Visa and the Federal Reserve Banks. See our Atlassian cloud migration services and Microsoft services, or contact us to scope a pilot. If you are also moving service desks, read our 90-day plan for Jira Service Management.