Migrare da Pivotal Tracker, Jira e altri tracker

East Agile Tracker importa da undici sorgenti. Dieci leggono il file di export che l’altro strumento produce già; GitHub si collega direttamente al repository. Ogni sorgente passa per la stessa schermata e la stessa anteprima, quindi i passaggi qui sotto valgono per tutte. Le sezioni successive elencano cosa porta ciascuna sorgente.

Importare un export

1. Esporta il tuo lavoro dall’altro strumento — la sezione della tua sorgente, più sotto, indica il menu.
2. Apri Project Settings → Import / Export sul progetto in cui vuoi le storie. Crea prima un progetto vuoto se ti serve.
3. Scegli l’origine e seleziona il file di export.
4. Esegui l’anteprima dry-run. Analizza l’intero file e riporta ciò che farebbe un’importazione reale — quante storie e label, quante righe vengono saltate e chiunque non sia riuscita ad abbinare a un membro — senza scrivere nulla.
5. Importa.

Reimportare lo stesso file è sicuro. Una riga già importata viene individuata dal suo id di origine e saltata, così una seconda esecuzione integra il progetto invece di duplicarlo.

Un upload è limitato a 10 MiB, e una singola importazione a 5.000 storie. Una migrazione più grande si suddivide in lotti e, poiché reimportare è idempotente, i lotti possono sovrapporsi senza creare duplicati.

Cosa porta ogni sorgente

• Storie, stati e label. Ogni riga o card diventa una storia, il suo status finisce sullo stato più vicino del ciclo unstarted → started → finished → delivered → accepted, e le sue label la accompagnano. Uno status annullato o «won’t fix» arriva rifiutato e archiviato, così il lavoro abbandonato resta fuori dalla board e fuori dalla velocity.
• Owner. Una cella con un indirizzo email che corrisponde a un membro collega quel membro. Qualsiasi altro valore — un nome visualizzato, un nome utente — collega una persona esterna di sola visualizzazione, così chi era owner di cosa sopravvive anche per chi non ha un account qui.
• Date. Le date di creazione e di completamento vengono importate, così le iterazioni storiche e i grafici che le leggono risultano popolati anziché vuoti.
• Iterazioni, per ogni sorgente il cui export contiene sprint o cicli.

Requester, commenti, epic e task dipendono dalla sorgente; la sua sezione, più sotto, dice quali.

Cosa non viene trasferito

• Gli allegati. Nessun importatore trasporta file. Le storie arrivano senza di essi.
• Le persone come account. Un owner, requester o commentatore che non è già membro viene collegato come persona esterna di sola visualizzazione. Nulla viene perso e nulla viene attribuito male, ma non viene creato nessun account e non viene inviato nessun invito — invitali normalmente e la loro cronologia è già collegata.
• Le date di ultima modifica. Non c’è un timestamp updated in ingresso.
• Le sfumature del workflow. Gli status personalizzati collassano sullo stato più vicino nel ciclo sopra. L’anteprima dry-run è il punto in cui controllare un campione prima di importare un progetto grande.

Da Pivotal Tracker

Origine: Pivotal Tracker (CSV export). Pivotal Tracker ha chiuso il 30 aprile 2025, quindi non esiste più un servizio attivo da cui esportare; ciò che questo importatore legge è un export CSV conservato da prima della chiusura. La board, gli stati delle storie e il ciclo di accettazione seguono lo stesso modello, così un progetto importato si legge come si leggeva prima.

Pivotal Tracker	Diventa
Title, Description	Il titolo e la descrizione della storia. La colonna URL viene conservata come provenienza della storia, e a una descrizione che contiene testo viene aggiunto un link View original issue.
Type	Il tipo di storia — feature, bug, chore e release hanno tutti un equivalente diretto.
Current State	Lo stato della storia.
Estimate	La stima in punti della storia.
Labels	Label, una per valore.
Owned By	Gli owner della storia. Pivotal ripete questa colonna per ogni owner e vengono lette tutte.
Requested By	Il requester della storia.
Comment (una colonna per commento)	I commenti della storia, con l’autore originale e il timestamp originale.
Task / Task Status	I task sulla storia, con i task completati che arrivano completati.
Blocker / Blocker Status	I blocker, con quelli risolti che arrivano risolti.
Le righe Type=epic	Epic veri, ricostruiti e uniti alle storie che li referenziano, con la descrizione dell’epic.
Iteration, Iteration Start	La griglia delle iterazioni. Le storie di un’iterazione che non era ancora iniziata restano nel Backlog, ordinate per sprint.
Created at, Accepted at	Le date di creazione e di completamento della storia.
Deadline	La data pianificata di una storia release.

Un export Pivotal non ha una colonna di inizio del lavoro, quindi i valori di cycle time restano vuoti per le storie importate. Una riga di epic che nessuna storia referenzia non crea nulla, perché gli epic vengono ricostruiti attraverso le loro storie membro.

Da Jira

Origine: Jira (CSV export). In Jira, cerca le issue che ti interessano, poi usa Export → Export Excel CSV (all fields). Prendi l’export con tutti i campi — l’export dei campi correnti omette le colonne di sprint, story point e commenti.

Jira	Diventa
Summary	Il titolo della storia. Una riga con il summary vuoto non viene importata.
Description	La descrizione della storia, convertita dal wiki markup di Jira a markdown. Intestazioni, grassetto, blocchi di codice, elenchi e link vengono convertiti; tutto il resto viene conservato come testo letterale.
Issue Type	Il tipo di storia — Bug diventa un bug, Story e Feature diventano feature, e Task diventa un chore.
Status	Lo stato della storia.
Priority	La priorità della storia, da Highest giù fino a Lowest.
Campo personalizzato degli story point	La stima della storia. Viene usata la prima colonna la cui intestazione menziona gli story point, quindi Custom field (Story Points) e Custom field (Story point estimate) funzionano entrambi.
Labels	Label, una per valore.
Fix Version/s	Una label Release: <version> per valore.
Sprint	La griglia delle iterazioni. Jira ripete la colonna una volta per ogni sprint attraversato dalla issue, e l’ultimo è quello in cui è finita; uno sprint con un nome sopravvive anche come label Sprint: <name>.
Assignee	L’owner della storia, come persona esterna di sola visualizzazione — un CSV di Jira non porta alcun indirizzo email con cui abbinare un membro.
Reporter	Il requester della storia, secondo la stessa regola.
Comment (una colonna per commento)	I commenti della storia, ciascuno con il suo autore e timestamp originali.
Le issue Sub-task	Task sulla storia padre, con i sotto-task conclusi che arrivano completati. Un sotto-task il cui padre manca nel file diventa una storia a sé.
Le issue Epic	Una label che prende il nome dall’epic, applicata a ogni issue figlia al suo interno.
Issue key	Accodata alla descrizione come testo semplice (Original issue: PROJ-12).
Created, Resolved	Le date di creazione e di completamento della storia.

Un epic di Jira arriva come label sui suoi figli anziché come record di epic: il raggruppamento sopravvive ed è ricercabile, la descrizione dell’epic stesso no. Jira esporta i nomi degli sprint ma non le loro date, quindi le iterazioni sono ordinate per nome di sprint.

Da Linear

Origine: Linear (CSV export) — in Linear, Workspace settings → Import/Export → Export CSV.

• Assignee diventa l’owner e Creator il requester.
• Project diventa l’epic della storia.
• Le sotto-issue diventano task sulla loro storia padre.
• I cicli costruiscono la griglia delle iterazioni; un ciclo non ancora iniziato tiene le sue storie nel Backlog, ordinate per ciclo.
• La colonna Started viene letta, quindi il cycle time funziona per le storie importate.
• Il CSV di Linear non ha una colonna del tipo: una storia con la label Bug arriva come bug, altrimenti come feature.
• L’export CSV di Linear non contiene commenti, e le issue archiviate vengono saltate.

Da Asana

Origine: Asana (CSV export) — in Asana, Project menu → Export/Print → CSV.

• Assignee diventa l’owner, abbinato a un membro tramite Assignee Email quando presente.
• I tag diventano label.
• I subtask diventano task sulla loro storia padre.
• Un’attività con una data in Completed At arriva accettata.
• Il CSV di Asana non ha né una colonna del creatore né commenti, quindi il membro che importa è il requester.

Da Trello

Origine: Trello (JSON export) — in Trello, Menu → Print and export → Export as JSON.

• Ogni card diventa una storia, e la lista in cui si trova ne fissa lo stato (To Do, Doing, Done e nomi simili).
• I membri di una card diventano owner.
• I commenti vengono trasferiti con i loro autori e timestamp.
• Gli elementi delle checklist diventano task.
• Le label mantengono nomi e colori; una label con un colore e senza nome arriva come Trello-<colour>.
• Una card archiviata arriva archiviata.
• Una card con la label Bug arriva come bug. Trello non ha né epic né stime, quindi non ne viene creato nessuno.

Da Shortcut

Origine: Shortcut (CSV export) — in Shortcut, Settings → Import/Export → Export to CSV.

• owners diventano gli owner e requester il requester.
• epic diventa l’epic della storia.
• tasks diventano task sulla storia; il CSV non registra alcun flag di completamento, quindi arrivano aperti.
• Le iterazioni costruiscono la griglia delle iterazioni.
• La colonna started_at viene letta, quindi il cycle time funziona per le storie importate.
• Una storia archiviata arriva archiviata. Il CSV di Shortcut non contiene commenti.

Da GitLab

Origine: GitLab (CSV export) — in GitLab, apri l’elenco delle issue e usa Export as CSV; GitLab ti invia il file via email.

• Una issue aperta arriva unstarted, una chiusa accepted.
• Weight diventa la stima.
• L’assegnatario diventa l’owner e l’autore il requester.
• L’URL della issue viene conservato come sua provenienza.
• Attiva Include milestones per fare di ogni milestone un epic; disattivato, la colonna delle milestone viene ignorata.
• Il CSV delle issue di GitLab non contiene commenti.

Da Plane

Origine: Plane (CSV export) o Plane (JSON export) — in Plane, Workspace settings → Exports.

• Ogni assegnatario diventa un owner.
• I commenti vengono trasferiti con i loro autori e timestamp.
• I gruppi di stati di Plane fissano lo stato; una issue annullata arriva rifiutata e archiviata.
• Un ciclo costruisce la griglia delle iterazioni e sopravvive anche come label Cycle: <name>; un modulo diventa una label Module: <name>.
• Gli export di Plane non hanno una colonna del creatore, quindi il membro che importa è il requester. Plane non esporta alcuna data di inizio del lavoro, quindi non c’è cycle time.

Da GitHub

Origine: GitHub (Issues via API). Inserisci l’owner e il repository invece di caricare un file. Le issue diventano storie con i loro assegnatari, l’autore, le label, i commenti e gli elementi delle checklist; pull request, milestone (come epic) e release sono opzionali. Token, limiti di frequenza e il resto si trovano in Popolare un progetto da un repo GitHub.

Da un altro progetto East Agile Tracker

Origine: East Agile Tracker (native export) — sull’altro progetto, Settings → Import / Export → Scarica esportazione. Questo è il percorso senza perdite: follower, revisori, epic, task, blocker, link e l’Icebox tornano tutti, e gli owner si ricollegano ai membri tramite email.

Dopo l’importazione

Le storie sono storie ordinarie — la macchina a stati, le iterazioni e la velocity valgono tutte. La stessa schermata riesporta il progetto più avanti, verso il formato East Agile Tracker per una copia senza perdite o nella forma di uno qualsiasi degli altri strumenti; vedi Istruzioni operative → Esportare un progetto.

Crea un progetto e importa il tuo export — l’importatore è sulla schermata delle impostazioni di ogni progetto.