Міграція з Pivotal Tracker, Jira та інших трекерів

East Agile Tracker імпортує з одинадцяти джерел. Десять читають файл експорту, який інший інструмент уже створює; GitHub підключається до репозиторію напряму. Кожне джерело проходить через той самий екран і той самий попередній перегляд, тож кроки нижче стосуються всіх. Наступні розділи перелічують, що переносить кожне джерело.

Імпортуйте експорт

1. Експортуйте свою роботу з іншого інструмента — розділ для вашого джерела нижче називає потрібне меню.
2. Відкрийте Project Settings → Import / Export у проєкті, куди ви хочете перенести історії. Якщо потрібно, спершу створіть порожній проєкт.
3. Виберіть джерело та вкажіть файл експорту.
4. Запустіть попередній перегляд dry-run. Він розбирає весь файл і повідомляє, що зробив би справжній імпорт — скільки історій і міток, скільки рядків пропущено та кого не вдалося зіставити з учасником, — і нічого не записує.
5. Імпортуйте.

Повторний імпорт того самого файлу безпечний. Рядок, який уже було імпортовано, зіставляється за своїм ідентифікатором у джерелі й пропускається, тож другий запуск доповнює проєкт, а не дублює його.

Завантаження обмежене 10 МіБ, а один імпорт — 5 000 історій. Більша міграція розділяється на партії, і оскільки повторний імпорт ідемпотентний, партії можуть перетинатися без створення дублікатів.

Що приносить кожне джерело

• Історії, стани та мітки. Кожен рядок або картка стає історією, її статус потрапляє на найближчий стан циклу unstarted → started → finished → delivered → accepted, а її мітки переносяться разом із нею. Статус «скасовано» або «won’t fix» прибуває відхиленим і заархівованим, тож покинута робота не потрапляє ні на дошку, ні до швидкості.
• Власники. Клітинка з електронною поштою, що відповідає учаснику, приєднує цього учасника. Будь-яке інше значення — відображуване ім’я, ім’я користувача — приєднує зовнішню особу, видиму лише за іменем, тож інформація про те, хто чим володів, зберігається навіть для людей без облікового запису тут.
• Дати. Дати створення та завершення імпортуються, тож історичні ітерації й графіки, що їх читають, заповнюються, а не лишаються порожніми.
• Ітерації — для кожного джерела, чий експорт містить спринти чи цикли.

Замовники, коментарі, епіки та завдання залежать від джерела; його розділ нижче вказує, які з них переносяться.

Що не переноситься

• Вкладення. Жоден імпортер не переносить файли. Історії прибувають без них.
• Люди як облікові записи. Власник, замовник або автор коментаря, який ще не є учасником, приєднується як зовнішня особа, видима лише за іменем. Нічого не втрачається й нічого не приписується помилково, але обліковий запис не створюється та запрошення не надсилається — запросіть їх звичайним чином, і їхня історія вже буде приєднана.
• Дати останньої зміни. Позначки часу updated на вході немає.
• Нюанси робочого процесу. Користувацькі статуси зводяться до найближчого стану в циклі вище. Попередній перегляд dry-run — те місце, де можна перевірити вибірку перед імпортом великого проєкту.

З Pivotal Tracker

Джерело: Pivotal Tracker (CSV export). Pivotal Tracker припинив роботу 30 квітня 2025 року, тож більше немає працюючого сервісу, з якого можна експортувати; цей імпортер читає CSV-експорт, збережений до закриття. Дошка, стани історій і цикл приймання дотримуються тієї самої моделі, тож імпортований проєкт читається так, як читався раніше.

Pivotal Tracker	Стає
Title, Description	Назва й опис історії. Стовпець URL зберігається як походження історії, а до опису, у якому є текст, додається посилання View original issue.
Type	Тип історії — feature, bug, chore і release мають прямий відповідник.
Current State	Стан історії.
Estimate	Оцінка історії в балах.
Labels	Мітки, по одній на значення.
Owned By	Власники історії. Pivotal повторює цей стовпець для кожного власника, і читається кожен із них.
Requested By	Замовник історії.
Comment (по одному стовпцю на коментар)	Коментарі історії, з первісним автором і первісною позначкою часу.
Task / Task Status	Завдання в історії, причому виконані завдання прибувають виконаними.
Blocker / Blocker Status	Блокери, причому вирішені прибувають вирішеними.
Рядки Type=epic	Справжні епіки, відтворені та з’єднані з історіями, які на них посилаються, разом з описом епіка.
Iteration, Iteration Start	Сітка ітерацій. Історії з ітерації, яка не розпочалася, залишаються в Backlog, упорядковані за спринтом.
Created at, Accepted at	Дати створення та завершення історії.
Deadline	Запланована дата історії типу release.

В експорті Pivotal немає стовпця з початком роботи, тож показники часу циклу для імпортованих історій залишаються порожніми. Рядок епіка, на який не посилається жодна історія, нічого не створює, бо епіки відтворюються через свої історії-учасники.

З Jira

Джерело: Jira (CSV export). У Jira знайдіть потрібні issues, а потім скористайтеся Export → Export Excel CSV (all fields). Беріть експорт з усіма полями — експорт із поточними полями не містить стовпців спринту, story points і коментарів.

Jira	Стає
Summary	Назва історії. Рядок із порожнім summary не імпортується.
Description	Опис історії, перетворений із вікі-розмітки Jira на markdown. Заголовки, жирний шрифт, блоки коду, списки й посилання перетворюються; усе інше зберігається як буквальний текст.
Issue Type	Тип історії — Bug стає bug, Story і Feature стають features, а Task стає chore.
Status	Стан історії.
Priority	Пріоритет історії, від Highest униз до Lowest.
Користувацьке поле story points	Оцінка історії. Використовується перший стовпець, у заголовку якого згадуються story points, тож працюють і Custom field (Story Points), і Custom field (Story point estimate).
Labels	Мітки, по одній на значення.
Fix Version/s	Мітка Release: <version> на кожне значення.
Sprint	Сітка ітерацій. Jira повторює цей стовпець по разу на кожен спринт, через який пройшло issue, і останній з них — той, де воно опинилося; названий спринт також зберігається як мітка Sprint: <name>.
Assignee	Власник історії, як зовнішня особа, видима лише за іменем, — CSV з Jira не містить адреси електронної пошти, за якою можна було б зіставити учасника.
Reporter	Замовник історії, за тим самим правилом.
Comment (по одному стовпцю на коментар)	Коментарі історії, кожен зі своїм первісним автором і позначкою часу.
Issues типу Sub-task	Завдання в батьківській історії, причому виконані підзавдання прибувають виконаними. Sub-task, батьківського елемента якого немає у файлі, стає окремою історією.
Issues типу Epic	Мітка, названа за епіком, застосована до кожного дочірнього issue в ньому.
Issue key	Додається в кінець опису як звичайний текст (Original issue: PROJ-12).
Created, Resolved	Дати створення та завершення історії.

Епік із Jira прибуває як мітка на своїх дочірніх елементах, а не як запис епіка: групування зберігається й доступне для пошуку, а власний опис епіка — ні. Jira експортує назви спринтів, але не їхні дати, тож ітерації впорядковуються за назвою спринту.

З Linear

Джерело: Linear (CSV export) — у Linear: Workspace settings → Import/Export → Export CSV.

• Assignee стає власником, а Creator — замовником.
• Project стає епіком історії.
• Sub-issues стають завданнями у своїй батьківській історії.
• Цикли будують сітку ітерацій; цикл, який не розпочався, залишає свої історії в Backlog, упорядковані за циклом.
• Стовпець Started читається, тож час циклу працює для імпортованих історій.
• У CSV з Linear немає стовпця типу: історія з міткою Bug прибуває як bug, інакше — як feature.
• CSV-експорт Linear не містить коментарів, а заархівовані issues пропускаються.

З Asana

Джерело: Asana (CSV export) — в Asana: Project menu → Export/Print → CSV.

• Assignee стає власником і зіставляється з учасником через Assignee Email, якщо він є.
• Теги стають мітками.
• Підзавдання стають завданнями у своїй батьківській історії.
• Завдання з датою Completed At прибуває прийнятим.
• У CSV з Asana немає стовпця автора й немає коментарів, тож замовником стає учасник, який виконує імпорт.

З Trello

Джерело: Trello (JSON export) — у Trello: Menu → Print and export → Export as JSON.

• Кожна картка стає історією, а список, у якому вона лежить, задає її стан (To Do, Doing, Done і схожі назви).
• Учасники картки стають власниками.
• Коментарі переносяться з авторами та позначками часу.
• Пункти чек-листів стають завданнями.
• Мітки зберігають свої назви та кольори; мітка з кольором, але без назви, прибуває як Trello-<colour>.
• Заархівована картка прибуває заархівованою.
• Картка з міткою Bug прибуває як bug. У Trello немає епіків і оцінок, тож ні те, ні інше не створюється.

З Shortcut

Джерело: Shortcut (CSV export) — у Shortcut: Settings → Import/Export → Export to CSV.

• owners стають власниками, а requester — замовником.
• epic стає епіком історії.
• tasks стають завданнями в історії; CSV не зберігає ознаку виконання, тож вони прибувають відкритими.
• Ітерації будують сітку ітерацій.
• Стовпець started_at читається, тож час циклу працює для імпортованих історій.
• Заархівована історія прибуває заархівованою. У CSV з Shortcut немає коментарів.

З GitLab

Джерело: GitLab (CSV export) — у GitLab відкрийте список issues і скористайтеся Export as CSV; GitLab надсилає файл вам електронною поштою.

• Відкрите issue прибуває у стані unstarted, закрите — accepted.
• Weight стає оцінкою.
• Виконавець стає власником, а автор — замовником.
• URL issue зберігається як його походження.
• Увімкніть Include milestones, щоб кожна віха стала епіком; якщо опцію вимкнено, стовпець віхи ігнорується.
• У CSV issues з GitLab немає коментарів.

З Plane

Джерело: Plane (CSV export) або Plane (JSON export) — у Plane: Workspace settings → Exports.

• Кожен виконавець стає власником.
• Коментарі переносяться з авторами та позначками часу.
• Групи станів Plane задають стан; скасоване issue прибуває відхиленим і заархівованим.
• Цикл будує сітку ітерацій і також зберігається як мітка Cycle: <name>; модуль стає міткою Module: <name>.
• В експортах Plane немає стовпця автора, тож замовником стає учасник, який виконує імпорт. Plane не експортує дату початку роботи, тож часу циклу немає.

З GitHub

Джерело: GitHub (Issues via API). Замість завантаження файлу вкажіть власника й репозиторій. Issues стають історіями зі своїми виконавцями, автором, мітками, коментарями та пунктами чек-листів; pull request’и, віхи (як епіки) та релізи — за вибором. Токени, ліміти запитів і решта описані в Наповнення проєкту з репозиторію GitHub.

З іншого проєкту East Agile Tracker

Джерело: East Agile Tracker (native export) — в іншому проєкті: Settings → Import / Export → Завантажити експорт. Це шлях без втрат: спостерігачі, рецензенти, епіки, завдання, блокери, зв’язки та Icebox повертаються повністю, а власники знову приєднуються до учасників за електронною поштою.

Після імпорту

Історії — це звичайні історії: машина станів, ітерації та швидкість застосовуються так само. Той самий екран згодом знову експортує проєкт — у формат East Agile Tracker для копії без втрат або у форму будь-якого з інших інструментів; див. Посібник користувача → Експорт проєкту.

Створіть проєкт і імпортуйте свій експорт — імпортер є на екрані налаштувань кожного проєкту.