Миграция из Pivotal Tracker, Jira и других трекеров

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

Импортируйте экспорт

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

Повторный импорт того же файла безопасен. Строка, которая уже была импортирована, сопоставляется по своему идентификатору в источнике и пропускается, так что второй запуск дополняет проект, а не дублирует его.

Загрузка ограничена 10 МиБ, а один импорт — 5000 историй. Более крупная миграция разбивается на партии, и поскольку повторный импорт идемпотентен, партии могут пересекаться, не создавая дубликатов.

Что приносит каждый источник

• Истории, состояния и метки. Каждая строка или карточка становится историей, её статус попадает в ближайшее состояние цикла unstarted → started → finished → delivered → accepted, а её метки переносятся вместе с ней. Статус «отменено» или «won’t fix» приходит как отклонённый и архивированный, так что брошенная работа не попадает ни на доску, ни в velocity.
• Владельцы. Ячейка с почтой, совпадающей с участником, присоединяет этого участника. Любое другое значение — отображаемое имя, имя пользователя — присоединяет внешнего человека, видимого только по имени, так что сведения о том, кто чем владел, сохраняются даже для людей без учётной записи здесь.
• Даты. Даты создания и завершения импортируются, так что исторические итерации и графики, которые их читают, заполняются, а не остаются пустыми.
• Итерации — для каждого источника, чей экспорт содержит спринты или циклы.

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

Что не переносится

• Вложения. Ни один импортёр не переносит файлы. Истории приходят без них.
• Люди как учётные записи. Владелец, заказчик или автор комментария, который ещё не является участником, присоединяется как внешний человек, видимый только по имени. Ничего не теряется и ничего не приписывается неверно, но учётная запись не создаётся и приглашение не отправляется — пригласите их обычным образом, и их история уже будет присоединена.
• Даты последнего изменения. Отметки времени 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 возвращаются полностью, а владельцы снова присоединяются к участникам по почте.

После импорта

Истории — обычные истории: машина состояний, итерации и velocity действуют так же. Тот же экран позже снова экспортирует проект — в формат East Agile Tracker для копии без потерь или в форму любого из других инструментов; см. Руководство пользователя → Экспорт проекта.

Создайте проект и импортируйте свой экспорт — импортёр есть на экране настроек каждого проекта.