Von Pivotal Tracker, Jira und anderen Trackern migrieren

East Agile Tracker importiert aus elf Quellen. Zehn lesen die Exportdatei, die das andere Tool ohnehin erzeugt; GitHub verbindet sich direkt mit dem Repository. Jede Quelle läuft über denselben Bildschirm und dieselbe Vorschau, die Schritte unten gelten also für alle. Die Abschnitte danach führen auf, was jede Quelle mitbringt.

Einen Export importieren

1. Exportieren Sie Ihre Arbeit aus dem anderen Tool — der Abschnitt zu Ihrer Quelle unten nennt das Menü.
2. Öffnen Sie Projekteinstellungen → Import / Export in dem Projekt, in das die Storys sollen. Legen Sie zuerst ein leeres Projekt an, wenn Sie eines brauchen.
3. Wählen Sie die Quelle und die Exportdatei aus.
4. Führen Sie die Dry-Run-Vorschau aus. Sie analysiert die gesamte Datei und meldet, was ein echter Import tun würde — wie viele Storys und Labels, wie viele Zeilen übersprungen werden und alle Personen, die sie keinem Mitglied zuordnen konnte —, und schreibt nichts.
5. Importieren.

Dieselbe Datei erneut zu importieren ist sicher. Eine Zeile, die schon importiert wurde, wird anhand ihrer Quell-ID abgeglichen und übersprungen, sodass ein zweiter Lauf das Projekt ergänzt, statt es zu duplizieren.

Ein Upload ist auf 10 MiB begrenzt und ein einzelner Import auf 5.000 Storys. Eine größere Migration teilt sich in Batches auf, und weil ein erneuter Import idempotent ist, dürfen sich die Batches überlappen, ohne Duplikate zu erzeugen.

Was jede Quelle mitbringt

• Storys, Zustände und Labels. Jede Zeile oder Karte wird eine Story, ihr Status landet auf dem nächstgelegenen Zustand der Schleife unstarted → started → finished → delivered → accepted, und ihre Labels kommen mit. Ein abgebrochener oder „won’t fix“-Status kommt als rejected und archiviert an, sodass aufgegebene Arbeit nicht im Board und nicht in der Velocity auftaucht.
• Eigentümer. Eine Zelle mit einer E-Mail-Adresse, die zu einem Mitglied passt, hängt dieses Mitglied an. Jeder andere Wert — ein Anzeigename, ein Benutzername — hängt eine nur zur Anzeige gedachte externe Person an, sodass erhalten bleibt, wem was gehörte, auch bei Personen ohne Konto hier.
• Daten. Erstellungs- und Abschlussdatum werden importiert, sodass historische Iterationen und die Diagramme, die sie lesen, gefüllt sind statt leer.
• Iterationen, für jede Quelle, deren Export Sprints oder Zyklen enthält.

Anforderer, Kommentare, Epics und Tasks hängen von der Quelle ab; ihr Abschnitt unten sagt, welche.

Was nicht übernommen wird

• Anhänge. Kein Importer trägt Dateien mit. Die Storys kommen ohne sie an.
• Personen als Konten. Ein Eigentümer, Anforderer oder Kommentator, der nicht schon Mitglied ist, wird als nur zur Anzeige gedachte externe Person angehängt. Nichts fällt weg und nichts wird falsch zugeordnet, aber es wird kein Konto angelegt und keine Einladung verschickt — laden Sie die Personen normal ein, und ihre Historie hängt schon dran.
• Änderungsdaten. Einen updated-Zeitstempel gibt es auf dem Weg herein nicht.
• Feinheiten des Workflows. Eigene Statuswerte fallen auf den nächstgelegenen Zustand in der Schleife oben zusammen. In der Dry-Run-Vorschau prüfen Sie eine Stichprobe, bevor Sie ein großes Projekt importieren.

Aus Pivotal Tracker

Quelle: Pivotal Tracker (CSV export). Pivotal Tracker wurde am 30. April 2025 abgeschaltet, es gibt also keinen laufenden Dienst mehr, aus dem exportiert werden könnte; dieser Importer liest einen CSV-Export, der vor der Abschaltung aufbewahrt wurde. Das Board, die Story-Zustände und die Akzeptanzschleife folgen demselben Modell, sodass ein importiertes Projekt sich liest wie vorher.

Pivotal Tracker	Wird zu
Title, Description	Titel und Beschreibung der Story. Die Spalte URL bleibt als Herkunft der Story erhalten, und einer Beschreibung, in der Text steht, wird ein Link View original issue hinzugefügt.
Type	Der Story-Typ — feature, bug, chore und release haben alle eine direkte Entsprechung.
Current State	Der Zustand der Story.
Estimate	Die Punkteschätzung der Story.
Labels	Labels, eines pro Wert.
Owned By	Die Eigentümer der Story. Pivotal wiederholt diese Spalte pro Eigentümer, und jede wird gelesen.
Requested By	Der Anforderer der Story.
Comment (eine Spalte pro Kommentar)	Story-Kommentare, mit dem ursprünglichen Autor und dem ursprünglichen Zeitstempel.
Task / Task Status	Tasks auf der Story, wobei erledigte Tasks erledigt ankommen.
Blocker / Blocker Status	Blocker, wobei gelöste gelöst ankommen.
Type=epic-Zeilen	Echte Epics, wiederaufgebaut und mit den Storys verbunden, die auf sie verweisen, samt der Beschreibung des Epics.
Iteration, Iteration Start	Das Iterationsraster. Storys aus einer Iteration, die noch nicht begonnen hatte, bleiben im Backlog, sortiert nach Sprint.
Created at, Accepted at	Erstellungs- und Abschlussdatum der Story.
Deadline	Das geplante Datum einer release-Story.

Ein Pivotal-Export hat keine Spalte für den Arbeitsbeginn, daher bleiben Durchlaufzeit-Werte für importierte Storys leer. Eine Epic-Zeile, auf die keine Story verweist, erzeugt nichts, weil Epics über ihre Mitglieds-Storys wiederaufgebaut werden.

Aus Jira

Quelle: Jira (CSV export). Suchen Sie in Jira nach den gewünschten Issues und verwenden Sie dann Export → Export Excel CSV (all fields). Nehmen Sie den All-Fields-Export — der Export der aktuellen Felder lässt die Spalten für Sprint, Story Points und Kommentare weg.

Jira	Wird zu
Summary	Der Titel der Story. Eine Zeile mit leerer Zusammenfassung wird nicht importiert.
Description	Die Beschreibung der Story, von Jira-Wiki-Markup nach Markdown konvertiert. Überschriften, Fettschrift, Codeblöcke, Listen und Links werden konvertiert; alles andere bleibt als wörtlicher Text erhalten.
Issue Type	Der Story-Typ — Bug wird ein Bug, Story und Feature werden Features, und Task wird ein Chore.
Status	Der Zustand der Story.
Priority	Die Priorität der Story, von Highest hinunter bis Lowest.
Story-Points-Custom-Field	Die Schätzung der Story. Verwendet wird die erste Spalte, deren Kopfzeile Story Points erwähnt, sodass Custom field (Story Points) und Custom field (Story point estimate) beide funktionieren.
Labels	Labels, eines pro Wert.
Fix Version/s	Ein Label Release: <version> pro Wert.
Sprint	Das Iterationsraster. Jira wiederholt die Spalte einmal pro Sprint, den ein Issue durchlaufen hat, und der letzte ist der, in dem es gelandet ist; ein benannter Sprint bleibt außerdem als Label Sprint: <name> erhalten.
Assignee	Der Eigentümer der Story, als nur zur Anzeige gedachte externe Person — ein Jira-CSV enthält keine E-Mail-Adresse, mit der ein Mitglied abgeglichen werden könnte.
Reporter	Der Anforderer der Story, nach derselben Regel.
Comment (eine Spalte pro Kommentar)	Story-Kommentare, jeder mit seinem ursprünglichen Autor und Zeitstempel.
Sub-task-Issues	Tasks auf der übergeordneten Story, wobei erledigte Sub-Tasks abgeschlossen ankommen. Ein Sub-Task, dessen Eltern-Issue in der Datei fehlt, wird eine eigene Story.
Epic-Issues	Ein Label, benannt nach dem Epic, angewendet auf jedes Kind-Issue darin.
Issue key	Als reiner Text an die Beschreibung angehängt (Original issue: PROJ-12).
Created, Resolved	Erstellungs- und Abschlussdatum der Story.

Ein Jira-Epic kommt als Label auf seinen Kindern an und nicht als Epic-Datensatz: Die Gruppierung bleibt erhalten und ist durchsuchbar, die Beschreibung des Epics selbst nicht. Jira exportiert Sprint-Namen, aber nicht deren Daten, daher werden Iterationen nach Sprint-Namen sortiert.

Aus Linear

Quelle: Linear (CSV export) — in Linear unter Workspace settings → Import/Export → Export CSV.

• Assignee wird der Eigentümer und Creator der Anforderer.
• Project wird das Epic der Story.
• Sub-Issues werden Tasks auf ihrer übergeordneten Story.
• Zyklen bilden das Iterationsraster; ein Zyklus, der noch nicht begonnen hat, behält seine Storys im Backlog, sortiert nach Zyklus.
• Die Spalte Started wird gelesen, sodass die Durchlaufzeit für importierte Storys funktioniert.
• Linears CSV hat keine Typ-Spalte: Eine Story mit dem Label Bug kommt als Bug an, sonst als Feature.
• Linears CSV-Export enthält keine Kommentare, und archivierte Issues werden übersprungen.

Aus Asana

Quelle: Asana (CSV export) — in Asana unter Project menu → Export/Print → CSV.

• Assignee wird der Eigentümer, über Assignee Email einem Mitglied zugeordnet, wenn eine vorhanden ist.
• Tags werden Labels.
• Subtasks werden Tasks auf ihrer übergeordneten Story.
• Eine Aufgabe mit einem Datum in Completed At kommt als accepted an.
• Asanas CSV hat weder eine Ersteller-Spalte noch Kommentare, daher ist das importierende Mitglied der Anforderer.

Aus Trello

Quelle: Trello (JSON export) — in Trello unter Menu → Print and export → Export as JSON.

• Jede Karte wird eine Story, und die Liste, in der sie liegt, legt ihren Zustand fest (To Do, Doing, Done und ähnliche Namen).
• Mitglieder einer Karte werden Eigentümer.
• Kommentare kommen mit ihren Autoren und Zeitstempeln mit.
• Checklisten-Einträge werden Tasks.
• Labels behalten ihre Namen und Farben; ein Label mit Farbe und ohne Namen kommt als Trello-<colour> an.
• Eine archivierte Karte kommt archiviert an.
• Eine Karte mit dem Label Bug kommt als Bug an. Trello hat weder Epics noch Schätzungen, daher wird keines von beiden angelegt.

Aus Shortcut

Quelle: Shortcut (CSV export) — in Shortcut unter Settings → Import/Export → Export to CSV.

• owners werden die Eigentümer und requester der Anforderer.
• epic wird das Epic der Story.
• tasks werden Tasks auf der Story; das CSV hält kein Erledigt-Kennzeichen fest, daher kommen sie offen an.
• Iterationen bilden das Iterationsraster.
• Die Spalte started_at wird gelesen, sodass die Durchlaufzeit für importierte Storys funktioniert.
• Eine archivierte Story kommt archiviert an. Shortcuts CSV enthält keine Kommentare.

Aus GitLab

Quelle: GitLab (CSV export) — öffnen Sie in GitLab die Issue-Liste und verwenden Sie Export as CSV; GitLab schickt Ihnen die Datei per E-Mail.

• Ein offenes Issue kommt als unstarted an, ein geschlossenes als accepted.
• Weight wird die Schätzung.
• Der Zuständige wird der Eigentümer und der Autor der Anforderer.
• Die URL des Issues bleibt als seine Herkunft erhalten.
• Schalten Sie Include milestones ein, um jeden Meilenstein zu einem Epic zu machen; ausgeschaltet wird die Meilenstein-Spalte ignoriert.
• GitLabs Issue-CSV enthält keine Kommentare.

Aus Plane

Quelle: Plane (CSV export) oder Plane (JSON export) — in Plane unter Workspace settings → Exports.

• Jeder Zuständige wird ein Eigentümer.
• Kommentare kommen mit ihren Autoren und Zeitstempeln mit.
• Planes Zustandsgruppen legen den Zustand fest; ein abgebrochenes Issue kommt als rejected und archiviert an.
• Ein Zyklus bildet das Iterationsraster und bleibt außerdem als Label Cycle: <name> erhalten; ein Modul wird ein Label Module: <name>.
• Plane-Exporte haben keine Ersteller-Spalte, daher ist das importierende Mitglied der Anforderer. Plane exportiert kein Datum für den Arbeitsbeginn, daher gibt es keine Durchlaufzeit.

Aus GitHub

Quelle: GitHub (Issues via API). Geben Sie den Eigentümer und das Repository ein, statt eine Datei hochzuladen. Issues werden Storys mit ihren Zuständigen, ihrem Autor, ihren Labels, Kommentaren und Checklisten-Einträgen; Pull Requests, Meilensteine (als Epics) und Releases sind Opt-in. Token, Ratenlimits und der Rest stehen unter Ein Projekt aus einem GitHub-Repo befüllen.

Aus einem anderen East-Agile-Tracker-Projekt

Quelle: East Agile Tracker (native export) — im anderen Projekt unter Einstellungen → Import / Export → Export herunterladen. Das ist der verlustfreie Weg: Follower, Reviewer, Epics, Tasks, Blocker, Links und die Icebox kommen alle zurück, und Eigentümer werden per E-Mail wieder Mitgliedern zugeordnet.

Nach dem Import

Die Storys sind gewöhnliche Storys — die Zustandsmaschine, Iterationen und Velocity gelten alle. Derselbe Bildschirm exportiert das Projekt später wieder, in das East-Agile-Tracker-Format für eine verlustfreie Kopie oder in die Form eines der anderen Tools; siehe Bedienungsanleitung → Ein Projekt exportieren.

Legen Sie ein Projekt an und importieren Sie Ihren Export — der Importer liegt auf dem Einstellungsbildschirm jedes Projekts.