How do you migrate from Jira to Azure DevOps Boards while preserving work item history and attachments?

Think of migrating from Jira to Azure DevOps Boards like translating a novel from one language to another while preserving not just the current text but every draft, editorial comment, and margin note. The characters (issue types) have different names in the new language, the grammar rules (workflows) structure sentences differently, and the punctuation marks (field types) have different symbols. A skilled translator does not just convert words: they map concepts, preserve the author's intent across revisions, and ensure readers of the translation understand the full creative journey. Jira-to-Azure-DevOps migration requires this same conceptual mapping combined with mechanical data transfer.

The first phase is mapping Jira's data model to Azure DevOps. Jira has issue types (Epic, Story, Task, Bug, Sub-task), custom fields (text, select, multi-select, date, user), and workflow states (configurable per project). Azure DevOps has work item types defined by process templates (Agile: Epic, Feature, User Story, Task, Bug; Scrum: Epic, Feature, PBI, Task, Bug). You must create a mapping table: Jira Epic maps to Azure DevOps Epic, Jira Story maps to User Story, Jira Sub-task maps to Task. Custom fields require creating matching fields in Azure DevOps with compatible types. Workflow states need mapping: Jira's 'In Review' might map to Azure DevOps 'Resolved' or a custom state. This mapping phase is intellectual work that cannot be automated and requires agreement from stakeholders who use both systems.

The migration tooling landscape offers several options. The Solidify Jira to Azure DevOps Work Item Migration Tool is an open-source solution that handles field mapping, history preservation, and attachment transfer. For enterprises, tools like OpsHub or Tasktop provide managed migration services with support. For custom requirements, you can build a migration pipeline using Jira's REST API (to export) and Azure DevOps REST API (to import). The custom approach gives maximum flexibility for complex field transformations, conditional logic, and validation, but requires significant development effort. Most organizations use a hybrid: a commercial tool for the bulk migration with custom scripts for edge cases like Jira plugins that store data in non-standard locations.

History preservation is the most challenging aspect. Jira stores a changelog for every field change on every issue, including who changed it and when. To preserve this in Azure DevOps, you must create work items with their historical field values and revision timestamps. Azure DevOps allows setting the ChangedDate and ChangedBy fields during import (using the bypassRules flag on the REST API), enabling you to recreate the revision history. Each Jira changelog entry becomes a work item revision in Azure DevOps. Comments transfer as Discussion entries with original timestamps and authors. Attachments are downloaded from Jira and uploaded to Azure DevOps work items. Links between issues (blocks, is-blocked-by, duplicates) map to Azure DevOps link types (Predecessor, Successor, Duplicate).

User identity mapping connects Jira usernames to Azure DevOps identities. Jira identifies users by accountId (cloud) or username (server), while Azure DevOps uses Azure AD email addresses. You create a mapping file that translates each Jira user to their Azure DevOps identity. For former employees who exist in Jira history but not in Azure AD, you can map them to a placeholder account or leave them as text references. The migration tool uses this mapping when setting AssignedTo, CreatedBy, and ChangedBy fields on imported work items, ensuring the history attributes correctly to real Azure DevOps users.

The production gotcha is the testing and validation cycle. Never migrate directly to your production Azure DevOps project on the first attempt. Create a test project, run the migration, and have stakeholders validate the results: Are all work items present? Do the field values look correct? Is the history complete? Are attachments accessible? Do parent-child relationships match Jira's hierarchy? Are sprint/iteration assignments correct? Expect to run 3-5 test migrations before the production run, adjusting field mappings and transformation rules each time. Another common issue is Jira's flexibility working against you: Jira allows essentially any field on any issue type, while Azure DevOps enforces type-specific field definitions. Issues that used fields in non-standard ways may require special handling during migration.