Project management
Jira to Polybase Migration: A Step-by-Step Guide
A Jira migration succeeds when the team can continue delivering work with clear ownership, reliable status information and access to the original context. Moving rows is only one part of that change. The harder decisions concern which fields matter, which workflows should remain and which history must stay available.
This guide explains how to plan a move from Jira to Polybase using a reviewed task spreadsheet and a controlled pilot. Polybase supports spreadsheet-based task import; this is not a claim of a complete Jira backup restore. Treat comments, attachments, hierarchy, historical changes and app-specific data as separate migration requirements.
1. Define the scope before exporting Jira
Start with one project and separate active work from historical reference. Include open tasks, upcoming commitments and the recently completed work needed to understand current delivery. Give older records an explicit archive decision rather than copying the entire backlog without review.
List the capabilities your team cannot operate without: sprint reporting, dependencies, custom workflows, time tracking, service requests or marketplace applications. Require a demonstrated destination workflow for each essential item. Polybase can be evaluated for connected chat, tasks and documents; specialist Jira requirements need their own acceptance decision.
2. Export a representative set of work items
In Jira Cloud, narrow the work-item search to the agreed project and scope, then use the export menu to download CSV with the required fields. Atlassian documents both current-field and all-field export options. These instructions concern Cloud; consult the documentation for your own edition if you use Data Center.
Keep the original export unchanged and prepare a separate working copy. Select examples with a long description, an unassigned owner, a custom status, multiple labels and a due date. A file that works for five simple tasks may still fail on the records that matter most.
3. Map Jira fields to the destination deliberately
Use Polybase’s spreadsheet source in the task import wizard, upload the prepared file and review the column mapping. Then review statuses, priorities and people before confirming the import. Suggested matches are a starting point; the project owner should approve their meaning.
The example below covers a practical starting set. Preserve the original Jira key and source URL in the description or migration register even when task identifiers can be retained. Do not assume every custom field has a native destination, or that an exported user name uniquely identifies an active teammate.
| Source field | Destination or treatment | Review |
|---|---|---|
| Summary / Description | Task title / description | Formatting and acceptance criteria |
| Status / Priority | Reviewed status / priority mapping | Meaning, not just matching labels |
| Assignee / Reporter | Assigned member / creator | Account matches and departed users |
| Labels / Due date | Labels / due date | Multiple values and date interpretation |
| Issue key / custom fields | Identifier where supported; otherwise reference text | Conflicts and information requiring separate treatment |
4. Rebuild the operating rules around the tasks
A status called “Review” does not preserve a Jira transition rule. Document who may move work, what must be complete first and who approves the result. Recreate and test the necessary controls in the destination. Polybase provides configurable task statuses and status approvals, but your existing Jira configuration does not become equivalent merely because the columns look similar.
Use a real handoff to validate the setup: a request becomes a task, the owner adds the relevant brief, a reviewer requests a correction and the task returns for approval. Check the list, board and timeline views against the same records. Reconnect notifications and development integrations only after that basic flow is reliable.
5. Reconcile the pilot before the final switch
Create a migration register with the source key, destination reference, batch, result and exception owner. Compare totals by status and assignee as well as the overall record count. A matching total can hide a project where every task has the wrong status.
Make a separate decision for comments, attachments, epic and subtask relationships, work logs, sprint history and automation rules. The spreadsheet task mapping described here does not establish that those objects transfer. Recreate required relationships or retain an accessible reference according to your agreed scope. Resolve essential gaps before switching.
- Check a sample of titles, descriptions, labels and dates against the source.
- Test member access and verify who can change protected statuses.
- Investigate every failed row before retrying; reconcile successful rows to avoid duplicates.
- Agree on a final update window, capture changes made during the pilot and nominate the person who approves cutover.
- Keep the agreed source reference available until owners accept the new working records.
Frequently asked questions
Can I import Jira tasks into Polybase using CSV?
Polybase has a spreadsheet task importer with configurable field and value mapping. Prepare a Jira CSV export and validate a sample through that route. This handles the mapped task fields; it should not be interpreted as a complete Jira project importer.
Will Jira comments, attachments and sprint history transfer?
Do not assume they transfer through the task spreadsheet wizard. They are outside the field mapping described in this guide. Inventory them separately and agree on a preservation or recreation method before moving essential projects.
How long does migration from Jira take?
The duration depends on active record volume, custom fields, integrations and the history you need to retain. Estimate it from a representative pilot and its unresolved exceptions rather than a fixed number of days.