Migrating Trello to Microsoft Planner: What We Learned Building PlannerBridge

Why migrate at all

Many companies grew up with Trello: boards for logistics, IT support, projects, onboarding. At some point Microsoft 365 arrives, and the question becomes whether to run two tools in parallel or consolidate. For a manufacturer with two sites we chose the second path and built our own tool for it: a local web app that rebuilds a complete Trello team export as Microsoft 365 plans, buckets and tasks.

The first prototype ran after two days. The finished tool took considerably longer. The difference lies in the details you only see once real boards with years of history go through the process.

A wizard, not a script

We deliberately built the migration as an 8-step wizard rather than a command-line script. Not because a script would not have been enough technically, but because the people who have to decide which board goes where are not developers. The steps in outline:

1. Read and validate the export
2. Sign in to Microsoft 365
3. Select boards
4. Assign target groups and plans
5. Member mapping (Trello users to Microsoft accounts)
6. Set rules for special cases
7. Dry run with a full report
8. Run the migration and check the log

Step 5 is where most of the time goes in practice. Trello usernames and Microsoft accounts rarely match cleanly, and former employees still appear on old cards.

The dry run is not an extra

The most important decision was to make the dry run complete: it executes every step except the writing calls and produces exactly the report the real migration would produce. Only then could the departments see what would happen to their boards before anything happened. A “preview” mode that merely prints counts would not have built that trust.

Idempotent and resumable

A migration over the Graph API will be interrupted. Not maybe – certainly. Tokens expire, the network drops, someone closes the laptop. So we built in two properties from the start:

• Idempotency: every created plan, bucket and task is tagged with its Trello ID. A repeated run recognises what already exists and creates nothing twice.
• Resumability: progress is stored locally. After an interruption the run continues where it stopped.

Without these two properties we would have had to clean up the target after every failure. With them, an interruption is an annoyance, not a problem.

Graph API throttling

The Graph API throttles under many requests, and Planner is on the strict side. Our client handles this explicitly: it reads the wait time from the response, pauses, and retries – with an upper bound after which the run stops cleanly instead of waiting forever. Ignore this and you get migrations that work on small boards and fail randomly on large ones.

The special cases that make the difference

Three things kept us busiest:

• Archived cards. Trello has them; Planner does not know the concept in the same form. We made it configurable: skip, put into a dedicated bucket, or mark as completed. Every department wanted something different.
• Over-long titles. Planner limits title length. Trello cards whose titles are really descriptions get truncated and the remainder moved into the description – with a note, so nothing is silently lost.
• Checklists. Here too there are limits on the number and length of items. Surplus items end up as text in the description so the information survives.

None of these cases is hard. But each of them breaks a migration if it is not known beforehand. The dry-run report lists all of them.

Takeaway

A migration between two tools is ninety percent handling edge cases and ten percent copying data. Anyone approaching it seriously builds in idempotency, resumability and a real dry run before the first card is transferred. The tool that came out of this is what we now offer as PlannerBridge.