Trello zu Microsoft Planner migrieren: Was wir beim Bau von PlannerBridge gelernt haben

Warum überhaupt migrieren

Viele Unternehmen sind mit Trello gross geworden: Boards für Spedition, IT-Support, Projekte, Onboarding. Irgendwann ist Microsoft 365 im Haus, und die Frage lautet, ob man zwei Werkzeuge parallel betreibt oder konsolidiert. Wir haben für einen Fertigungsbetrieb mit zwei Standorten den zweiten Weg gewählt und dafür ein eigenes Werkzeug gebaut: eine lokale Web-App, die einen kompletten Trello-Team-Export als Microsoft-365-Pläne, Buckets und Tasks nachbaut.

Der erste Prototyp lief nach zwei Tagen. Das fertige Werkzeug brauchte deutlich länger. Der Unterschied liegt in den Details, die man erst sieht, wenn echte Boards mit Jahren Geschichte durch den Prozess laufen.

Ein Wizard, nicht ein Skript

Wir haben die Migration bewusst als 8-Schritt-Wizard gebaut und nicht als Kommandozeilenskript. Nicht weil ein Skript technisch nicht gereicht hätte, sondern weil die Personen, die entscheiden müssen, welches Board wohin geht, keine Entwickler sind. Die Schritte im Groben:

1. Export einlesen und validieren
2. Anmeldung gegen Microsoft 365
3. Boards auswählen
4. Zielgruppen und Pläne zuordnen
5. Mitglieder-Mapping (Trello-Nutzer zu Microsoft-Konten)
6. Regeln für Sonderfälle festlegen
7. Dry-Run mit vollständigem Bericht
8. Migration ausführen und Protokoll prüfen

Schritt 5 ist der, an dem in der Praxis am meisten Zeit hängt. Trello-Nutzernamen und Microsoft-Konten stimmen selten sauber überein, und ehemalige Mitarbeitende tauchen in alten Karten immer noch auf.

Der Dry-Run ist kein Extra

Die wichtigste Entscheidung war, den Dry-Run vollständig zu machen: Er führt jeden Schritt aus, bis auf die schreibenden Aufrufe, und erzeugt exakt den Bericht, den die echte Migration erzeugen würde. Erst damit konnten die Fachabteilungen sehen, was mit ihren Boards passiert, bevor etwas passiert. Ein «Vorschau»-Modus, der nur Zahlen ausgibt, hätte das Vertrauen nicht geschaffen.

Idempotent und wiederaufnehmbar

Eine Migration über die Graph API bricht ab. Nicht vielleicht – sicher. Token laufen ab, das Netzwerk hat einen Aussetzer, jemand schliesst den Laptop. Wir haben deshalb von Anfang an zwei Eigenschaften eingebaut:

• Idempotenz: Jeder erzeugte Plan, Bucket und Task wird mit seiner Trello-ID markiert. Ein erneuter Lauf erkennt, was schon existiert, und legt nichts doppelt an.
• Wiederaufnahme: Der Fortschritt wird lokal gespeichert. Nach einem Abbruch geht es an der Stelle weiter, an der es aufgehört hat.

Ohne diese beiden Eigenschaften hätten wir nach jedem Fehler das Ziel aufräumen müssen. Mit ihnen ist ein Abbruch ein Ärgernis, kein Problem.

Throttling der Graph API

Die Graph API drosselt bei vielen Anfragen, und Planner ist dabei eher streng. Unser Client behandelt das explizit: Er liest die Wartezeit aus der Antwort, pausiert, und versucht es erneut – mit einer Obergrenze, nach der der Lauf sauber gestoppt wird statt endlos zu warten. Wer das ignoriert, bekommt Migrationen, die bei kleinen Boards funktionieren und bei grossen zufällig scheitern.

Die Sonderfälle, die den Unterschied machen

Drei Dinge haben uns am meisten beschäftigt:

• Archivierte Karten. Trello hat sie, Planner kennt das Konzept nicht in derselben Form. Wir haben es konfigurierbar gemacht: überspringen, in einen eigenen Bucket legen oder als erledigt markieren. Jede Abteilung wollte etwas anderes.
• Überlange Titel. Planner begrenzt die Titellänge. Trello-Karten, deren Titel eigentlich Beschreibungen sind, werden gekürzt und der Rest in die Beschreibung verschoben – mit Hinweis, damit nichts stillschweigend verloren geht.
• Checklisten. Auch hier gibt es Grenzen bei Anzahl und Länge der Einträge. Überzählige Einträge landen als Text in der Beschreibung, damit die Information erhalten bleibt.

Keiner dieser Fälle ist schwierig. Aber jeder von ihnen zerstört eine Migration, wenn er nicht vorher bekannt ist. Der Dry-Run-Bericht listet sie alle auf.

Fazit

Eine Migration zwischen zwei Werkzeugen ist zu neunzig Prozent Umgang mit Grenzfällen und zu zehn Prozent das Kopieren von Daten. Wer sie ernsthaft angeht, baut Idempotenz, Wiederaufnahme und einen echten Dry-Run ein, bevor die erste Karte übertragen wird. Das Werkzeug, das daraus entstanden ist, bieten wir heute als PlannerBridge an.