Migrate Planner to another tenant: what carries and what cannot
Plans, buckets, tasks, checklists, labels and assignments move through Graph; creation dates and completers cannot be back-dated. Here is the full list.
Planner is the workload most often left off a migration plan and most often asked about the week after cutover. Plans belong to Microsoft 365 groups, every team has at least one, and project teams live in them. To migrate Planner to another tenant, or between groups in the same tenant, a tool has to rebuild each plan through the Graph Planner API, because neither Microsoft's cross-tenant migration nor Migration Orchestrator moves Planner. This article lists exactly what that API lets a tool carry, what it cannot, and how to run it so a re-run never duplicates a task.
How Planner is structured, and why it matters
A plan is owned by a group, and a group can own several plans. Each plan has up to 25 category labels (category1 to category25) with their names, a set of buckets in a chosen order, and tasks. A task has a title, a bucket, a position in the bucket, assignees, a priority, start and due dates, a percent complete, applied labels, and a details object with a description, a checklist in order, and attachment references, which are URLs with an alias and a type rather than files.
Two things follow. First, the destination group has to exist before anything can be created, and if the plan belongs to a team, that team should be migrated first so the plan lands in the right place; the Teams migration guide covers that sequence. Second, every Planner update has to carry the object's current etag in an If-Match header, so a tool must read before it writes and use the representation Graph returns to chain updates, or it will spend most of its time on conflicts.
What carries
| Planner object | Carried | How |
|---|---|---|
| Plan | Yes | Created in the destination group with the source title, or an existing plan with the same title is reused |
| Category labels | Yes | All 25 category descriptions written to the plan details |
| Buckets | Yes, in order | Created in source order; existing same-named buckets reused on re-run |
| Tasks | Yes, in board order | Created bucket by bucket; the position inside the bucket is copied with one extra read and write per task, which can be turned off for speed |
| Assignments | Yes, mapped | Source assignee to UPN, mapped UPN, destination user id; anything unresolved is a warning and the assignee is dropped |
| Priority, start date, due date, percent complete | Yes | Written on the task |
| Applied labels | Yes | Mapped to the same category slots |
| Description and preview type | Yes | Written to task details |
| Checklist | Yes, in order | Items are added one at a time, each placed after the previous, because items sent together get server-chosen order hints with no guaranteed sequence |
| Attachment references | Yes, as references | URLs with alias and type; a prefix rewrite maps source SharePoint links to the migrated library |
Everything in that table is idempotent through a JSON state file that records every destination id as soon as Graph returns it. A crash or a cancelled run resumes where it stopped, and a second run against the same state file creates nothing new unless the source has new tasks.
What cannot be back-dated or carried
The Planner API sets createdDateTime and createdBy when an object is created, and sets completedDateTime and completedBy when a task reaches 100 percent. None of them accepts a value from the caller. So in the destination, every migrated task shows the migration date and the migration app as its creator, and every completed task shows the migration as its completer.
That is a Graph limitation, not a tool choice, and no tool can avoid it. What a tool can do is preserve the information somewhere visible. ShareShift appends a footer to each task's description of the form “Migrated from Planner: created 2024-03-01 by Jane Doe; completed 2024-03-05 by John Doe”, including only the parts that are known, and the footer can be turned off if you would rather keep descriptions clean.
| Not carried | Reason | Mitigation |
|---|---|---|
| Task created date and creator | Set by Graph at creation; not writable | Recorded in the description footer |
| Task completed date and completer | Set by Graph when percent complete reaches 100; not writable | Recorded in the description footer |
| Attachment files themselves | References are URLs, not blobs | Migrate the SharePoint library first and rewrite the URL prefixes |
| Assignees who cannot be mapped | No destination user | Warning per task; the task is still created |
| Plan-level created date | Same Graph rule | Nothing to do; the plan title and contents carry |
Step by step
- Grant the permission. The destination app needs the Graph application permission
Tasks.ReadWrite.Allin addition to the Teams and SharePoint permissions; the source app needs it to read plans, buckets, tasks and details. Allow about five minutes after consent before tokens carry the role. - Migrate the group or team first. A plan needs a destination group. If the team is being migrated with its channels, do that run first so the plan lands with its team.
- Migrate the SharePoint library that holds the attached documents, so attachment references can be rewritten to live URLs.
- Map users. A CSV of source to destination UPNs, or a domain rewrite such as
@old.com=@new.com, drives assignees. Expect warnings for departed people. - Run the plan migration with a state file. Migrate all plans in the group, or name specific plans by title or id, and optionally reuse an existing destination plan with the same title.
- Review warnings: unmapped assignees and dropped or unrewritten attachment references are listed per task.
- Re-run before cutover to pick up tasks created since; existing ones are skipped by id.
shareshift planner --source-group "Finance Team" --dest-group "Finance Team" \ --source-tenant-id <old> --tenant-id <new> --client-id <app> --pfx ./app.pfx \ --map-domain @old.com=@new.com \ --rewrite-url https://old.sharepoint.com/sites/finance=https://new.sharepoint.com/sites/finance \ --state ./shareshift-planner.json
How the tools compare on Planner
Microsoft's own cross-tenant SharePoint and OneDrive migration does not move Planner, and Migration Orchestrator explicitly excludes shared data such as Teams channels and SharePoint sites; Planner is not in its scope either. ShareGate lists Planner among the workloads on every tier, alongside SharePoint, Teams, OneDrive and file shares. ShareShift includes Planner on every plan with no workload gating, and the same Graph limits apply to any tool: nothing can back-date task creation or completion.
The practical difference between tools is therefore in the details: whether board order and checklist order are preserved, whether assignees are mapped and verified rather than dropped silently, whether attachment references are rewritten, and whether a re-run is safe. Those are the four questions to put to any vendor. The tenant to tenant guide shows where Planner sits in the overall sequence, and the pricing page has the plans and the 30-day trial. For a feature by feature view against ShareGate, see the comparison page.
Frequently asked questions
Can Planner be migrated to another tenant?
Yes, through the Graph Planner API: plans, category labels, buckets in order, tasks in board order, assignments, priority, dates, progress, descriptions, checklists and attachment references. Microsoft's native cross-tenant tools do not move Planner.
Are Planner task creation dates preserved?
No. Graph sets createdDateTime, createdBy, completedDateTime and completedBy itself and does not accept values from the caller, so migrated tasks show the migration date. ShareShift records the original dates and people in a footer on each task description.
Do Planner attachments migrate?
Attachments are URL references, not files. The references are carried and their URL prefixes can be rewritten to the migrated SharePoint library, which should be migrated first.
What permission does a Planner migration need?
The Graph application permission Tasks.ReadWrite.All on the app in each tenant, plus the destination group must already exist. If the plan belongs to a team, migrate the team first.
Run your first migration on a 30-day free trial
Every workload, unlimited data, three workers, pause and resume built in. Worker-only, so your content never passes through our servers. The trial key is issued from the portal and works with the same app you would buy.