Moving from Azure DevOps to Jira sounds straightforward until you actually start mapping the data.
The challenge isn't exporting work items. It's translating two different ways of organizing software projects. Azure DevOps and Jira use different issue hierarchies, workflows, identity models, and project structures. If you simply copy data from one to the other, you'll probably end up with missing relationships, lost history, or workflows that no longer make sense.
I've seen the same migration pattern come up repeatedly, whether the move is driven by a company merger, a shift to the Atlassian ecosystem, or a broader tooling consolidation.
This guide walks through the process step by step.
TL;DR
A successful Azure DevOps to Jira migration typically involves:
- Auditing your Azure DevOps project before migrating
- Mapping work item types to Jira issue types
- Translating workflows, iterations, and custom fields
- Mapping user identities between Microsoft Entra ID and Jira accounts
- Choosing the right migration approach (CSV, REST APIs, or a migration tool)
- Running a pilot migration first
- Validating everything before cutover
- Switching to Jira on a planned date instead of running both systems indefinitely
The migration itself isn't usually the difficult part. The planning is.
Step 1: Audit your Azure DevOps project
Before touching Jira, understand exactly what you're migrating.
Start by collecting:
- Work item types
- Number of work items
- Custom fields
- Attachments
- Comments
- Area Paths
- Iterations
- Parent-child relationships
- Linked work items
This is also a good time to clean up your Azure DevOps project.
Look for:
- Broken links
- Missing required fields
- Invalid users
- Obsolete custom fields
- Attachments that no longer exist
Cleaning these up before migration is significantly easier than fixing them afterward.
Step 2: Map Azure DevOps work items to Jira issue types
The first design decision is deciding how Azure DevOps work items translate into Jira.
A common mapping looks like this:
The biggest question is usually Feature.
Unlike Azure DevOps, Jira doesn't include a default Feature issue type. Most organizations either:
- Map Features to Epics, or
- Create a custom Feature issue type
- Make that decision before migration begins
- Changing it halfway through creates unnecessary rework
Step 3: Translate workflows
Workflows rarely match perfectly.
For example:
Azure DevOps
New
↓
Active
↓
Resolved
↓
Closed
Typical Jira workflow
To Do
↓
In Progress
↓
Done
If your Azure DevOps process includes custom states like:
- In Review
- QA Testing
- Blocked
- Ready for Release
Decide whether those become custom Jira statuses or map to existing ones.
The same applies to custom fields. Every field should have a destination in Jira. Fields without a mapping won't necessarily trigger an error. They simply won't appear after migration.
Step 4: Map iterations and area paths
Azure DevOps uses two concepts that don't directly exist in Jira.
- Iterations
- Iterations generally become Jira Sprints.
If multiple teams share iterations, verify that your Jira boards will represent them correctly.
Area Paths
Area Paths often become:
- Components
- Labels
- Custom fields
The right choice depends on how your organization uses Area Paths today.
Step 5: Map user identities
This step is frequently overlooked.
- Azure DevOps identifies users through Microsoft Entra ID.
- Jira Cloud identifies users using Atlassian account IDs.
Those identities aren't interchangeable.
Build a mapping between Azure DevOps users and Jira accounts before migrating.
Email addresses are usually the safest matching method.
Without user mapping you may end up with:
- Missing assignees
- Incorrect reporters
- Lost ownership history
Step 6: Choose a migration approach
There isn't a single best migration method.
The right choice depends on your data and how much history you need to preserve.
Option 1: CSV import
Best for:
- Small projects
- Simple backlogs
- Minimal historical data
Pros:
- 1. Easy to use
- 2. No coding required
Limitations:
- Limited history
- No comments
- Limited attachment support
- Relationship mapping can be difficult
Option 2: REST APIs
Both Azure DevOps and Jira expose comprehensive REST APIs.
This approach gives you maximum flexibility.
You'll need to handle:
- Authentication
- Pagination
- Rate limits
- Attachments
- Comments
- Relationships
- Retry logic
- Validation
It's powerful, but it also requires engineering effort.
Option 3: Dedicated migration tools
Purpose-built migration tools like OpsHub Migration Manager (OMM) connect directly to both systems and automate much of the migration process.
These migration tools (like OMM) typically support:
- Field mapping
- Workflow mapping
- User mapping
- Attachments
- Comments
- Complete history
- Relationship preservation
They're often the preferred option for larger migrations where data fidelity matters.
Learn more about Azure DevOps to Jira migration with OMM.
Step 7: Run a pilot migration
Never migrate everything first.
Select:
- One project
- one team
- Representative subset
Then compare every migrated issue against the original.
Verify:
- Fields
- Comments
- Attachments
- Status
- History
- Links
- Parent-child relationships
This is where most mapping problems are discovered.
Step 8: Validate the full migration
Once the pilot succeeds, validate the larger migration carefully.
Check that:
- Work item counts match
- Attachments open correctly
- Comments are complete
- Authors are correct
- Dates are preserved
- Links still work
- Sprint assignments are accurate
- Custom fields migrated correctly
Don't rely solely on automated reports.
Spot-check actual issues.
Step 9: Plan the cutover
Eventually there needs to be a clear transition.
Choose a cutover date. From that point:
- Stop creating work in Azure DevOps.
- Move active work to Jira.
- Keep Azure DevOps available as read-only if historical reference is needed.
Running both systems as active sources usually creates synchronization problems and confusion.
Book a free migration demo slot.
Common migration mistakes
These issues appear in many Azure DevOps to Jira migrations:
- Using CSV when preserving comments and history is important
- Forgetting to map custom fields
- Ignoring user identity mapping
- Skipping a pilot migration
- Leaving linked work items outside the migration scope
- Assuming workflows will translate automatically
Most migration problems aren't caused by the migration itself.
They're caused by planning assumptions.
Frequently Asked Questions
Q1) Can Azure DevOps comments be migrated to Jira?
Ans 1) Yes. However, CSV imports don't preserve comment history. API-based migrations and dedicated migration tools can typically migrate comments, authorship, and timestamps.
Q2) Does Azure DevOps Feature map directly to Jira?
Ans 2) No. Most teams either map Feature to Epic or create a custom Jira issue type.
Q3) How should users be mapped?
Ans 3) The most reliable approach is matching Azure DevOps users to Jira accounts using email addresses before migration begins.
Q4) How long does an Azure DevOps to Jira migration take?
Ans4) It depends on:
- Number of work items
- Attachments
- Historical data
- Customizations
- Validation effort
A phased migration with pilot testing is generally more predictable than migrating everything at once.
Q5) What's the safest way to test the migration?
Ans 5) Run a pilot on a small project or representative dataset, validate the results thoroughly, then scale up once the mappings have been confirmed.
Final thoughts
An Azure DevOps to Jira migration isn't simply about copying data from one platform to another.
It's about translating how your teams organize work, collaborate, and track progress.
Investing time in mapping work item types, workflows, custom fields, users, and project structures before migration will save far more time than trying to repair missing or inconsistent data afterward.
Whether the move is driven by a merger, an enterprise-wide standardization on Jira, or broader tool consolidation, careful planning and incremental validation make the migration significantly more predictable and far less stressful.
If you're planning this migration and have questions about mapping workflows, preserving history, or choosing the right migration approach, drop them in the comments. Let's discuss.
Top comments (0)