Migracja z Pivotal Trackera, Jiry i innych trackerów

East Agile Tracker importuje z jedenastu źródeł. Dziesięć czyta plik eksportu, który inne narzędzie już tworzy; GitHub łączy się z repozytorium bezpośrednio. Każde źródło przechodzi przez ten sam ekran i ten sam podgląd, więc poniższe kroki dotyczą ich wszystkich. Kolejne sekcje wymieniają, co każde źródło przenosi.

Zaimportuj eksport

1. Wyeksportuj swoją pracę z innego narzędzia — sekcja dla Twojego źródła poniżej podaje odpowiednie menu.
2. Otwórz Project Settings → Import / Export w projekcie, w którym chcesz mieć historie. Jeśli potrzebujesz, utwórz najpierw pusty projekt.
3. Wybierz źródło i wskaż plik eksportu.
4. Uruchom podgląd dry-run. Parsuje cały plik i raportuje, co zrobiłby prawdziwy import — ile historii i etykiet, ile wierszy zostanie pominiętych i kogo nie udało się dopasować do członka — i niczego nie zapisuje.
5. Zaimportuj.

Ponowny import tego samego pliku jest bezpieczny. Wiersz, który już został zaimportowany, jest dopasowywany po swoim identyfikatorze źródłowym i pomijany, więc drugie uruchomienie uzupełnia projekt, a nie duplikuje go.

Przesyłanie jest ograniczone do 10 MiB, a pojedynczy import do 5000 historii. Większa migracja dzieli się na partie, a ponieważ ponowny import jest idempotentny, partie mogą się nakładać bez tworzenia duplikatów.

Co przynosi każde źródło

• Historie, stany i etykiety. Każdy wiersz lub karta staje się historią, jej status trafia na najbliższy stan pętli unstarted → started → finished → delivered → accepted, a jej etykiety przychodzą razem z nią. Status anulowany lub „won’t fix” przychodzi jako odrzucony i zarchiwizowany, więc porzucona praca nie trafia na tablicę ani do prędkości.
• Właściciele. Komórka z adresem e-mail dopasowanym do członka dołącza tego członka. Każda inna wartość — nazwa wyświetlana, nazwa użytkownika — dołącza osobę zewnętrzną widoczną tylko z nazwy, więc informacja o tym, kto co posiadał, przetrwa nawet dla osób, które nie mają tu konta.
• Daty. Daty utworzenia i ukończenia są importowane, więc historyczne iteracje oraz wykresy, które je czytają, są wypełnione, a nie puste.
• Iteracje, dla każdego źródła, którego eksport zawiera sprinty lub cykle.

Zgłaszający, komentarze, epiki i zadania zależą od źródła; jego sekcja poniżej mówi, które się przenoszą.

Co się nie przenosi

• Załączniki. Żaden importer nie przenosi plików. Historie przychodzą bez nich.
• Osoby jako konta. Właściciel, zgłaszający lub komentujący, który nie jest już członkiem, jest dołączany jako osoba zewnętrzna widoczna tylko z nazwy. Nic nie jest tracone i nic nie jest przypisane błędnie, ale żadne konto nie jest tworzone i żadne zaproszenie nie jest wysyłane — zaproś ich normalnie, a ich historia już będzie dołączona.
• Data ostatniej modyfikacji. Nie ma znacznika updated na wejściu.
• Niuanse przepływu pracy. Niestandardowe statusy zapadają się na najbliższy stan w pętli powyżej. Podgląd dry-run to miejsce, by sprawdzić próbkę przed importem dużego projektu.

Z Pivotal Trackera

Źródło: Pivotal Tracker (CSV export). Pivotal Tracker zakończył działalność 30 kwietnia 2025, więc nie ma już działającej usługi, z której dałoby się eksportować; ten importer czyta eksport CSV zachowany sprzed zamknięcia. Tablica, stany historii i pętla akceptacji podążają za tym samym modelem, więc zaimportowany projekt czyta się tak, jak czytał się wcześniej.

Pivotal Tracker	Staje się
Title, Description	Tytuł i opis historii. Kolumna URL jest zachowywana jako pochodzenie historii, a do opisu, który zawiera tekst, dodawany jest odnośnik View original issue.
Type	Typ historii — feature, bug, chore i release mają bezpośrednie odpowiedniki.
Current State	Stan historii.
Estimate	Punktowa estymacja historii.
Labels	Etykiety, jedna na wartość.
Owned By	Właściciele historii. Pivotal powtarza tę kolumnę dla każdego właściciela i każda z nich jest czytana.
Requested By	Zgłaszający historię.
Comment (jedna kolumna na komentarz)	Komentarze historii, z pierwotnym autorem i pierwotnym znacznikiem czasu.
Task / Task Status	Zadania w historii, przy czym ukończone zadania przychodzą ukończone.
Blocker / Blocker Status	Blokery, przy czym rozwiązane przychodzą rozwiązane.
Wiersze Type=epic	Prawdziwe epiki, odtworzone i połączone z historiami, które się do nich odwołują, razem z opisem epiku.
Iteration, Iteration Start	Siatka iteracji. Historie z iteracji, która się nie rozpoczęła, pozostają w Backlogu, uszeregowane według sprintu.
Created at, Accepted at	Data utworzenia i ukończenia historii.
Deadline	Planowana data historii typu release.

Eksport z Pivotala nie ma kolumny z początkiem pracy, więc wartości czasu cyklu pozostają puste dla zaimportowanych historii. Wiersz epiku, do którego nie odwołuje się żadna historia, nie tworzy niczego, bo epiki są odtwarzane przez swoje historie członkowskie.

Z Jiry

Źródło: Jira (CSV export). W Jirze wyszukaj issues, które chcesz, a potem użyj Export → Export Excel CSV (all fields). Weź eksport ze wszystkimi polami — eksport z bieżącymi polami pomija kolumny sprintu, story pointów i komentarzy.

Jira	Staje się
Summary	Tytuł historii. Wiersz z pustym podsumowaniem nie jest importowany.
Description	Opis historii, przekonwertowany ze znaczników wiki Jiry na markdown. Nagłówki, pogrubienia, bloki kodu, listy i odnośniki są konwertowane; wszystko inne zostaje zachowane jako tekst dosłowny.
Issue Type	Typ historii — Bug staje się bugiem, Story i Feature stają się features, a Task staje się chore.
Status	Stan historii.
Priority	Priorytet historii, od Highest w dół do Lowest.
Pole niestandardowe ze story pointami	Estymacja historii. Używana jest pierwsza kolumna, której nagłówek wspomina o story pointach, więc działają zarówno Custom field (Story Points), jak i Custom field (Story point estimate).
Labels	Etykiety, jedna na wartość.
Fix Version/s	Etykieta Release: <version> na każdą wartość.
Sprint	Siatka iteracji. Jira powtarza tę kolumnę raz na każdy sprint, przez który przeszło issue, a ostatni z nich jest tym, w którym się znalazło; nazwany sprint przetrwa także jako etykieta Sprint: <name>.
Assignee	Właściciel historii, jako osoba zewnętrzna widoczna tylko z nazwy — CSV z Jiry nie zawiera adresu e-mail, który dałoby się dopasować do członka.
Reporter	Zgłaszający historię, na tej samej zasadzie.
Comment (jedna kolumna na komentarz)	Komentarze historii, każdy ze swoim pierwotnym autorem i znacznikiem czasu.
Issues typu Sub-task	Zadania w historii nadrzędnej, przy czym ukończone podzadania przychodzą ukończone. Sub-task, którego rodzica brakuje w pliku, staje się osobną historią.
Issues typu Epic	Etykieta nazwana od epiku, nadana każdemu jego issue potomnemu.
Issue key	Dopisywany do opisu jako zwykły tekst (Original issue: PROJ-12).
Created, Resolved	Data utworzenia i ukończenia historii.

Epik z Jiry przychodzi jako etykieta na swoich potomkach, a nie jako rekord epiku: grupowanie przetrwa i da się przeszukiwać, opis samego epiku nie. Jira eksportuje nazwy sprintów, a nie ich daty, więc iteracje są porządkowane według nazwy sprintu.

Z Linear

Źródło: Linear (CSV export) — w Linear, Workspace settings → Import/Export → Export CSV.

• Assignee staje się właścicielem, a Creator zgłaszającym.
• Project staje się epikiem historii.
• Sub-issues stają się zadaniami w swojej historii nadrzędnej.
• Cykle budują siatkę iteracji; cykl, który się nie rozpoczął, zostawia swoje historie w Backlogu, uszeregowane według cyklu.
• Kolumna Started jest czytana, więc czas cyklu działa dla zaimportowanych historii.
• CSV z Linear nie ma kolumny typu: historia z etykietą Bug przychodzi jako bug, w przeciwnym razie jako feature.
• Eksport CSV z Linear nie zawiera komentarzy, a zarchiwizowane issues są pomijane.

Z Asany

Źródło: Asana (CSV export) — w Asanie, Project menu → Export/Print → CSV.

• Assignee staje się właścicielem, dopasowanym do członka przez Assignee Email, jeśli jest dostępny.
• Tagi stają się etykietami.
• Podzadania stają się zadaniami w swojej historii nadrzędnej.
• Zadanie z datą Completed At przychodzi jako zaakceptowane.
• CSV z Asany nie ma kolumny z autorem ani komentarzy, więc zgłaszającym jest członek wykonujący import.

Z Trello

Źródło: Trello (JSON export) — w Trello, Menu → Print and export → Export as JSON.

• Każda karta staje się historią, a lista, na której leży, ustala jej stan (To Do, Doing, Done i podobne nazwy).
• Członkowie na karcie stają się właścicielami.
• Komentarze przenoszą się razem z autorami i znacznikami czasu.
• Elementy list kontrolnych stają się zadaniami.
• Etykiety zachowują swoje nazwy i kolory; etykieta z kolorem, ale bez nazwy, przychodzi jako Trello-<colour>.
• Zarchiwizowana karta przychodzi zarchiwizowana.
• Karta z etykietą Bug przychodzi jako bug. Trello nie ma epików ani estymacji, więc nie powstaje ani jedno, ani drugie.

Z Shortcut

Źródło: Shortcut (CSV export) — w Shortcut, Settings → Import/Export → Export to CSV.

• owners stają się właścicielami, a requester zgłaszającym.
• epic staje się epikiem historii.
• tasks stają się zadaniami w historii; CSV nie zapisuje znacznika ukończenia, więc przychodzą jako otwarte.
• Iteracje budują siatkę iteracji.
• Kolumna started_at jest czytana, więc czas cyklu działa dla zaimportowanych historii.
• Zarchiwizowana historia przychodzi zarchiwizowana. CSV z Shortcut nie zawiera komentarzy.

Z GitLaba

Źródło: GitLab (CSV export) — w GitLabie otwórz listę issues i użyj Export as CSV; GitLab wysyła plik e-mailem.

• Otwarte issue przychodzi jako unstarted, zamknięte jako accepted.
• Weight staje się estymacją.
• Osoba przypisana staje się właścicielem, a autor zgłaszającym.
• URL issue jest zachowywany jako jego pochodzenie.
• Włącz Include milestones, aby każdy kamień milowy stał się epikiem; gdy opcja jest wyłączona, kolumna kamienia milowego jest ignorowana.
• CSV z issues GitLaba nie zawiera komentarzy.

Z Plane

Źródło: Plane (CSV export) lub Plane (JSON export) — w Plane, Workspace settings → Exports.

• Każda osoba przypisana staje się właścicielem.
• Komentarze przenoszą się razem z autorami i znacznikami czasu.
• Grupy stanów Plane ustalają stan; anulowane issue przychodzi jako odrzucone i zarchiwizowane.
• Cykl buduje siatkę iteracji i przetrwa też jako etykieta Cycle: <name>; moduł staje się etykietą Module: <name>.
• Eksporty z Plane nie mają kolumny z autorem, więc zgłaszającym jest członek wykonujący import. Plane nie eksportuje daty rozpoczęcia pracy, więc nie ma czasu cyklu.

Z GitHuba

Źródło: GitHub (Issues via API). Zamiast przesyłać plik, podaj właściciela i repozytorium. Issues stają się historiami razem z osobami przypisanymi, autorem, etykietami, komentarzami i elementami list kontrolnych; pull requesty, kamienie milowe (jako epiki) i releasy są opcjonalne. Tokeny, limity zapytań i reszta są opisane w Zapełnij projekt z repozytorium GitHub.

Z innego projektu East Agile Trackera

Źródło: East Agile Tracker (native export) — w drugim projekcie, Settings → Import / Export → Pobierz eksport. To ścieżka bezstratna: obserwujący, recenzenci, epiki, zadania, blokery, powiązania i Icebox wracają w całości, a właściciele są ponownie dołączani do członków po adresie e-mail.

Po imporcie

Historie są zwykłymi historiami — maszyna stanów, iteracje i prędkość obowiązują tak samo. Ten sam ekran wyeksportuje projekt później ponownie, do formatu East Agile Trackera dla bezstratnej kopii albo do postaci dowolnego z pozostałych narzędzi; zobacz Instrukcja obsługi → Eksportowanie projektu.

Utwórz projekt i zaimportuj swój eksport — importer jest na ekranie ustawień każdego projektu.