You mirror Jira epics in Planner by turning each epic into a single Planner task, so the people who watch delivery but don’t live in Jira can follow progress from Teams without paying for a Jira seat. The catch is keeping that mirror current: done by hand it’s a snapshot that goes stale the moment an epic moves. This page covers what to mirror, how the fields line up, and how to keep it in sync.

Why mirror Jira epics in Planner at all?

Because the audience is split by license, not by interest. Your developers work in Jira and always will. But the managers, execs, and cross-functional partners who just want to know “is this epic on track” often don’t have a Jira seat, and giving them one isn’t free. Jira is free for up to 10 users, and past that every seat is paid, starting at $7.91 per user per month on the Standard plan (Atlassian). Buying seats for people who will only ever read is hard to justify.

Planner sits on the other side of that line. It ships inside Microsoft Teams, and the new Planner app reached general availability in Fall 2024, bringing plans and tasks into the same Teams surface people already open every day (Microsoft Support). Teams itself passed 320 million monthly active users, per Microsoft’s own count (Microsoft Community Hub). So the odds are the stakeholders you’d otherwise buy Jira seats for are already in Teams. Mirror the epics into a Planner plan and they watch delivery where they already are, at no extra license cost.

What does “mirror an epic as a Planner task” actually mean?

It means one Planner task per epic, and only the epic level. You’re not copying every story, sub-task, and bug into Planner. That would recreate the Jira noise you were trying to spare people from. You lift the epics, because an epic is the unit leadership actually tracks: a shippable chunk of work with an owner and a target date.

The fields line up like this:

Jira epicPlanner taskNote
Epic name / summaryTask titleClean 1:1.
Epic statusProgress, or a bucketMap your workflow’s statuses to Planner’s Not started / In progress / Completed, or use buckets as status columns.
Epic assignee / leadAssigned toWorks if the person exists as a Planner user in the same tenant.
Due date / target endDue date1:1.
Epic link / keyTask notesDrop the Jira URL in the notes so anyone who does have a seat can click through.

The rule that keeps this clean: pick which Jira epics you mirror with a JQL filter, not by hand. Something like issuetype = Epic AND project = ABC AND statusCategory != Done gives you exactly the live epics worth showing, and nothing else.

How do you do it by hand?

The manual route works for a one-time snapshot:

  1. Filter to epics. In Jira, run a JQL search that returns just the epics you want to show (project, epic issue type, not-done).
  2. Read the fields. For each epic, note the summary, status, assignee, and due date.
  3. Rebuild in Planner. Create a plan, add one task per epic, and set the bucket, assignee, and due date to match.
  4. Paste the link. Put the Jira epic key or URL in the task notes so it’s traceable.

It’s fine for a launch update or a board meeting. It falls apart as an ongoing thing, because Jira doesn’t stand still. An epic slips a sprint, a status flips, an owner changes, and your Planner mirror is now quietly wrong. Every refresh is you doing steps 2 and 3 again, and the day you skip it is the day leadership is looking at stale delivery data.

How do you keep the Planner mirror current?

You automate the refresh. A live mirror reads the epics from your JQL filter on a schedule and updates the matching Planner tasks: status changes, date slips, reassignments, all of it, without anyone re-keying. Scope it to the epic level so you get the delivery view and not the full Jira firehose, and keep it one direction (Jira drives, Planner reflects) so nobody’s edits in Planner accidentally overwrite the source of truth.

That’s exactly what Microsoft Planner to Jira does. You point it at a JQL filter scoped to your epics, choose the target Planner plan, and it mirrors each epic as a Planner task and keeps them current on a sync cycle. Your developers stay in Jira, your stakeholders watch the epics from Teams, and you stop buying read-only Jira seats or rebuilding the same plan by hand every Monday.