Jira to Azure DevOps Migration

It is a fixed-scope project in which IT Partner moves the Jira Cloud or Jira Data Center projects you nominate into Azure Boards: inventory, target design and process choice, the field, state, link and user mapping workbook, a verified pilot, the production migration inside an agreed Jira freeze, reconciliation, boards and iteration configuration, and a team briefing. Estimated at $3,950 per project and about 3 weeks, confirmed as a fixed written quote after the inventory, with payment after you approve delivery.

No. Microsoft's Data Migration Tool imports Azure DevOps Server and TFS collections, not Jira. The standard path is Solidify's open-source Jira to Azure DevOps migrator, which exports issues by JQL query and imports them as work items with field data, state, history, comments, attachments and links; commercial migrators are the alternative where they fit better, and Azure Boards' native CSV import covers genuinely small, simple sets. We name the tool, edition and release we will use in the quote.

Yes, to the extent the tool documents. Comments are written into the work item's history and discussion, attachments are downloaded from Jira and re-uploaded to the work item (within Azure DevOps' 100 attachments and 60 MB per file limits), and issue history is replayed as revisions so created and changed dates survive. Attribution depends on the user mapping: mapped users keep their names, unmapped ones fall back to a default identity, which is why departed staff and service accounts get an explicit decision in the workbook.

They get redesigned, not copied — that is the consulting half of this engagement. Each Jira status maps to an Azure Boards state and its state category (which drives board columns), each custom field maps to an Azure DevOps field by reference name, and anything without an equivalent is listed by name with a proposed trade-off. Fields you no longer use are a good thing to leave behind, and the workbook is where that conversation happens, before the import rather than after.

Basic for the lightest tracking (Epic, Issue, Task), Agile if you track user stories with separate test work, Scrum if you run product backlog items and sprints, CMMI if you need formal change control with requirements, change requests, risks and reviews — or an inherited process derived from one of them when you need custom fields, states or work item types. Microsoft owns and locks the four system processes, and the base process is chosen when the project is created, so we make this decision in design and not after the import.

Sprints map to the Azure Boards iteration tree, with sprint dates carried where the tool tier supports them; Jira epics map to the parent-child hierarchy through the epic link field; components usually become area paths or tags depending on whether they represent teams or categories; and versions map to Fix Version and Affects Version fields or to tags, with full release migration being a paid-tier feature. Every one of those choices is written in the mapping workbook and shown to you in the pilot.

Not necessarily. Solidify's Community edition is free and open source and covers most migrations. The PRO and suite tiers are subscriptions bought from the vendor and add releases and Fix/Affects Version, sprint dates, Bitbucket branch links, remote-link conversion, rewriting of embedded Jira links, custom state-transition dates and — in the suite — test management and Confluence wikis. If your estate needs those, the licence is your cost and we say so in the inventory rather than burying it in the fee.

Not with this service. The migrator is explicitly a one-time migration tool and its own guidance is a production stop in Jira for the final run; long-running two-way synchronisation is a different product category with its own licences and its own failure modes. What we do plan is a short freeze, a delta pass for anything created in it, and Jira left read-only so nobody loses a reference.

This engagement re-points links so migrated work items point at repositories that already live in Azure Repos or GitHub, and configures development links where the tool and your repository state support it. Moving the repositories themselves — branches, tags, pull request history, permissions — is a separate quoted project. Anything we cannot re-point is listed in writing rather than left to be discovered.

Yes, as a separately quoted project, and with the fidelity stated up front. Neither Atlassian nor GitHub ships a first-party Jira exporter for that path, so it relies on community importers whose coverage varies — a Jira issue with several fix versions has one GitHub milestone to land in, custom fields become labels or body text, and votes and watchers do not carry. If GitHub is where your teams already work, that may still be the right destination; tell us and we will scope the honest version of it.

Both are out of scope here and both are real projects in their own right. Confluence spaces move to SharePoint Online — that is Confluence to SharePoint Online Migration — or to Azure DevOps wikis, with different tooling and a different information architecture in each case. Jira Service Management — queues, request types, SLAs, approvals and the customer portal — is a service desk, and Azure Boards is not one; replacing it lands on different Microsoft products and is scoped separately.

Your teams work normally in Jira through the inventory, the mapping workbook and the pilot. The only stop is the freeze for the projects in scope during the production run, and its length is measured from the pilot rather than guessed — it is driven by issue count, attachment volume and Jira API throughput. After cutover, Jira stays read-only as a safety net until you decide to retire it.

They are logged, not lost. The tool keeps a journal of what has been imported, so a run can be resumed and failed items re-run after the configuration is corrected — a mistyped field reference name is the classic cause. The reconciliation report compares counts by project, type and status against Jira, lists links and attachments transferred, and shows every error with its disposition before we call the migration complete.

Azure DevOps Services is billed by Microsoft per user: Stakeholder access is free, the first five Basic users in an organization are free on Microsoft's published pricing, Visual Studio subscribers are typically covered, and additional Basic users are paid monthly. We confirm what your team needs during the inventory, but check the current rates against Microsoft's published pricing — they are Microsoft's numbers, not ours, and they change on Microsoft's schedule.

$3,950 is the typical price for migrating the Jira projects you nominate from a single Jira site with the tooling the inventory selects. The inventory in week one turns it into a fixed written quote — covering the number of projects and issues in scope, the tool tier, and any add-ons such as test management or repository work — which you approve before migration work begins. Per IT Partner's standard terms, you pay after you approve delivery.

The shape does; the price does not. Large estates are quoted per estate after the inventory, usually as waves: a pilot wave that proves the mapping, then batches grouped by team or process so each freeze is short and each verification has a real owner. The inventory is where 'migrate everything' becomes a list with counts against it — and where archiving dead projects in place often removes more work than any tool does.