There’s no native, one-click migration from Microsoft Planner to Jira — and the CSV export-import route everyone reaches for loses your buckets, checklists, and assignees in field-mapping hell. The fix is to decide the Planner-to-Jira field crosswalk before you import, or use a connector that does the mapping in one pass. This page covers both.
The pain is well documented. The canonical Atlassian Community migration thread is built entirely around matching Planner fields — “Bucket Name, Checklist Items, Completed Checklist items, Labels, Late” — to Jira, and the accepted answer walks through ticking a manual “Map field value” box for each one (Atlassian Community). Another thread frames it as going from a “napkin to a blueprint” — the two tools model work differently enough that a raw dump doesn’t survive the trip (Atlassian Community).
The manual route: CSV export and import
The DIY path is four steps:
- Export the plan. From Planner (or via the Microsoft 365 export), get the plan’s tasks into a CSV or Excel file.
- Clean the columns. Planner exports fields like Bucket, Progress, Priority, Assigned To, Checklist items, Labels, Start, Due, and Late. Some map cleanly; some don’t.
- Import into Jira. Use Jira’s external-system CSV import and map each column to a Jira field by hand.
- Map field values. For every Planner value that has no Jira equivalent, tick “Map field value” and choose a target — one row at a time.
It works for a one-time move of a small plan. It falls apart on volume, and step 4 is where things silently go missing.
The Planner → Jira field crosswalk
Decide these mappings once, up front, and apply them consistently:
| Planner | Jira | Note |
|---|---|---|
| Task title | Summary | Clean 1:1. |
| Notes / description | Description | 1:1, but Planner’s formatting is thinner. |
| Bucket | Status, component, label, or board column | No single right answer — pick one convention before importing. |
| Progress (Not started / In progress / Completed) | Status | Map the three Planner states to your workflow’s statuses. |
| Assigned To | Assignee | Only works if the person exists as a Jira user with a matching identity. |
| Checklist items | Sub-tasks or a description checklist | No native Planner-checklist equivalent in Jira; choose sub-tasks (heavier, trackable) or inline (lightweight, not trackable). |
| Priority | Priority | Map Planner’s Urgent/Important/Medium/Low to your scheme. |
| Labels | Labels | 1:1. |
| Start / Due date | Start date / Due date | 1:1 if your Jira has the fields enabled. |
| Late (flag) | (no field) | Derived from due date in Jira — drop the flag, don’t map it. |
The two that bite people are buckets and checklists, because neither has a native Jira twin. If you don’t decide their target field before you import, the same bucket ends up scattered across statuses on one task and labels on another.
Why the DIY route stays painful
Even done carefully, the CSV path is a one-time snapshot. It doesn’t keep Planner and Jira in sync afterward, so if some of the team stays in Planner during a phased move, the two drift apart immediately. Building it as a live integration by hand means wiring the Microsoft Planner API to the Jira API yourself — the kind of multi-step glue job that platforms like Pipedream exist to paper over (Pipedream).
The one-pass alternative
If you’d rather not do CSV surgery, point a purpose-built connector at the plan and let it recreate the tasks as Jira issues with buckets, checklists, and assignees mapped in a single pass — and keep them in sync afterward if you need a phased cutover.
That’s what the Microsoft Planner to Jira Connector does: install it from the Marketplace, choose the plan and the target Jira project, and it handles the field crosswalk above so you’re not ticking “Map field value” a hundred times. See the quickstart for the exact setup.