Миграция с Jira на Plane: пошаговый план для команды до 100 человек

Переезд с Jira на Plane в 2026 году стал типовой задачей: Atlassian закрыла продажи Data Center, а облачные тарифы дорожают. У Plane есть штатный импортер из Jira Cloud и Jira Server/Data Center, который переносит проекты, задачи, комментарии, вложения и пользователей. Но хорошая миграция не переносит всё. Она переносит то, что нужно команде для работы, и оставляет позади сложность, которая накопилась за годы.

Это практическое руководство по переезду для команды до 100 человек. План основан на документации Plane и нашем опыте внедрений, с поправками на казахстанскую специфику: self-hosted развёртывание на серверах в стране и ответственность за инфраструктуру. Почему переезд вообще стал актуален, мы разобрали в статье о закрытии Jira Data Center, а сравнение инструментов в статье Plane или Jira.

Путь миграции целиком

Этап	Что делаем	Результат
1. Границы	Решаем, какие проекты и задачи переезжают	Список проектов для переноса и для архива
2. Аудит	Инвентаризируем Jira по 25 областям	Таблица зависимостей, скриптов и приложений
3. Подготовка	Готовим рабочее пространство Plane и доступы к Jira	Пространство, токен API, фильтр JQL
4. Пилот	Импортируем один проект, проверяем с реальными пользователями	Решение о готовности к полному переносу
5. Волны	Переносим остальные проекты, переподключаем интеграции	Все команды в Plane
6. Переключение	Переводим Jira в режим чтения, фиксируем правила	Plane как единственная система учёта
7. Стабилизация	Ревизия адопции через 2–4 недели, отключение Jira	Контракт с Atlassian закрыт

Шаг 1. Решаем, что переезжает

Первый вопрос не «как перенести», а «что не переносить». В типичной Jira трёх-пятилетней давности половина проектов закрыта, а треть статусов не используется. Переносить это в новую систему означает сразу загрязнить её.

Правила, которые мы применяем:

• активные проекты переезжают целиком с историей;
• закрытые проекты переезжают, только если на них ссылаются регламенты, договоры или аудит; остальные экспортируются в архив;
• закрытые задачи старше года переносятся по решению владельца проекта, чаще уходят в архив;
• несколько мелких проектов одной команды объединяются в один проект Plane с модулями.

Для каждого проекта фиксируем, кто принимает решение о его судьбе. Без этого миграция застревает на согласованиях.

Шаг 2. Аудит Jira

Plane предлагает проверить Jira примерно по 25 областям вручную или с помощью скрипта Jira Discovery, который собирает инвентарь в таблицу. Ключевые пункты:

1. Число активных пользователей за 90 дней и их роли.
2. Проекты, схемы workflow и статусы с частотой использования.
3. Типы задач и кастомные поля, по каждому полю: используется ли оно в фильтрах и отчётах.
4. Связи между задачами и подзадачи.
5. Спринты, версии, компоненты, эпики.
6. Автоматизации Jira Automation.
7. Скрипты ScriptRunner и Groovy, пост-функции.
8. Приложения из Marketplace и данные, которые они хранят.
9. Интеграции: GitHub, GitLab, Bitbucket, CI/CD, Slack, Sentry, CRM.
10. Дашборды и фильтры JQL, которыми реально пользуются руководители.
11. Вложения: общий объём и самые большие файлы.
12. Схемы прав и группы пользователей.

Результат аудита: таблица, где напротив каждой сущности стоит одно из трёх решений: переносится автоматически, собирается заново в Plane, не переносится.

Шаг 3. Подготовка Plane и доступов

Со стороны Plane: рабочее пространство создано, администратор назначен, развёртывание выбрано. Для компаний в Казахстане с требованиями к хранению данных это self-hosted установка через Docker или Kubernetes на сервере у местного хостера или в собственном дата-центре. До импорта стоит проверить резервное копирование и восстановление: миграция будет первым серьёзным объёмом данных в системе.

Контекст Казахстана. Self-hosted Plane на сервере казахстанского хостера оставляет данные в стране, если компании это важно. Но ответственность за сервер, обновления и резервные копии переходит к вам. До старта миграции назначьте инженера или подрядчика, который будет сопровождать систему после запуска.

Со стороны Jira: токен API администратора, адрес инстанса, почта пользователя, при необходимости фильтр JQL для ограничения импорта. Для Jira Server и Data Center учитывайте лимит активных мест: пользователи сверх лимита импортируются в приостановленном состоянии и активируются позже.

Шаг 4. Как работает импортер

Импортер Plane живёт в настройках рабочего пространства. Процесс для Jira Cloud и для Server/Data Center различается деталями подключения, но логика одна: вы указываете источник, выбираете проекты, сопоставляете состояния и пользователей, запускаете импорт. Он может занимать от нескольких минут до нескольких часов в зависимости от объёма вложений.

По завершении доступен отчёт Import Summary: что импортировано, что пропущено, где ошибки. Этот отчёт становится основой проверки пилота. Все перенесённые задачи помечаются меткой JIRA IMPORTED.

Импорт можно запускать повторно для всех типов развёртывания. Для Server и Data Center прерванный импорт можно возобновить примерно в течение семи дней.

Шаг 5. Маппинг: что во что превращается

Сущность Jira	В Plane	Решение
Project	Project	Автоматически, возможна консолидация
Issue	Work item	Автоматически
Issue type	Work item type	Автоматически, лишние типы объединяются
Status и workflow	States в группах состояний	Сопоставление вручную при импорте
Priority, labels	Priority, labels	Автоматически
Sprint	Cycle	Автоматически
Component, Version	Module	Автоматически
Epic	Work item type «Epic», не Epics Plane	Решение после импорта
Sub-task	Sub-work item	Автоматически
Issue links	Relations	Автоматически
Comments, attachments	Comments, attachments	Автоматически
Users	Members	Сопоставление по почте
Custom fields	Properties типа задачи	Частично, зависит от типа поля
Jira Automation	Automations, Runner	Собирается заново
ScriptRunner, Groovy	Нет аналога	Собирается заново или не переносится
Dashboards, JQL filters	Dashboards, PQL, Views	Собирается заново
Permission schemes	Roles, Granular Access Control	Собирается заново
Confluence	Pages, Wiki	Отдельный импорт или ручной перенос
Marketplace apps	Нет аналога	Оценивается по каждому приложению

Самая дорогая часть любой миграции внизу таблицы: автоматизации, скрипты и отчёты. Их объём определяет, будет переезд занимать шесть недель или полгода.

Шаг 6. Пилот и его проверка

Пилотный проект выбираем так: 10–20 активных пользователей, живой поток задач, не самая сложная схема workflow, но с типичными для компании полями и связями. Импортируем, затем проверяем с командой по чек-листу:

• число задач в Jira и Plane совпадает с учётом фильтра;
• случайная выборка из 20 задач: описание, комментарии, вложения, исполнитель, статус на месте;
• связи между задачами и подзадачи сохранились;
• спринты превратились в циклы с правильными датами;
• пользователи сопоставлены, никто не потерял авторство;
• интеграция с Git-репозиторием пересобрана и коммиты привязываются к задачам;
• команда поработала в Plane неделю и зафиксировала вопросы.

Пилот это ворота принятия решения. Если он не прошёл, полный перенос не готов. Возвращаемся к маппингу, а не двигаемся дальше по плану.

Шаг 7. План по неделям для 100 человек

Неделя	Действия	Кто участвует
1	Границы миграции, аудит Jira, таблица решений	Владелец процесса, администратор Jira, подрядчик
2	Развёртывание Plane, резервные копии, доступы, SSO	Инженер инфраструктуры
3	Импорт пилотного проекта, проверка по чек-листу	Пилотная команда
4	Работа пилотной команды в Plane, сбор замечаний, донастройка	Пилотная команда, владелец процесса
5	Первая волна: 40–50% проектов, переподключение интеграций	Команды волны, инженер
6	Вторая волна, пересборка автоматизаций и дашбордов	Остальные команды
7	Переключение: Jira в режим чтения, регламент, обучение	Вся компания

Срок рассчитан на подготовленную Jira и выделенного владельца процесса. Если аудит показал сотни проектов и десятки скриптов, план пересчитывается после первой недели.

Чек-лист переключения

• Все проекты из списка перенесены, отчёты Import Summary проверены.
• Интеграции с Git, CI/CD, мессенджером и CRM работают из Plane.
• Автоматизации и дашборды руководителей пересобраны.
• Jira переведена в режим только для чтения, создание новых задач закрыто.
• Команды знают правило: новые задачи только в Plane.
• Назначен владелец Plane внутри компании и подрядчик по инфраструктуре.
• Экспорт Jira сохранён в архив на случай спорных вопросов.

Стабилизация

Через две-четыре недели после переключения проводим ревизию: все ли команды работают в Plane, нет ли параллельного учёта в чатах или в старой Jira, работают ли интеграции. Частичное использование Jira в этот период главный риск: две системы учёта означают, что ни одной нельзя доверять. По итогам ревизии Jira отключается, а подписка с Atlassian не продлевается.

Мы проводим миграции с Jira на Plane целиком: аудит, развёртывание на серверах в Казахстане, импорт, пересборка автоматизаций и обучение команды. Подробнее на странице услуги внедрения таск-трекеров Jira и Plane.

---

Источники. Документация импортера Plane и руководство по миграции с Jira в блоге Plane, август 2026 года. Таймлайн Atlassian Data Center: atlassian.com/enterprise/data-center.

Термины простыми словами

Импортер

Встроенный в Plane инструмент, который переносит данные из Jira. Все перенесённые задачи получают метку JIRA IMPORTED, чтобы их было легко найти и проверить.

Маппинг

Таблица соответствий: во что превращается каждый объект Jira в Plane. Например, спринт становится циклом, а компонент или версия — модулем.

Токен API

Секретный ключ, по которому одна программа получает доступ к данным другой. Для импорта нужен токен администратора Jira.

JQL-фильтр

Запрос на языке поиска Jira, который отбирает нужные задачи. С его помощью можно ограничить, что именно попадёт в импорт.

ScriptRunner

Дополнение к Jira для собственных скриптов на языке Groovy. В Plane аналога нет, поэтому такую логику переписывают другими средствами или от неё отказываются.

Адопция

То, насколько команда реально пользуется новой системой. Ревизия через две-четыре недели проверяет, не ведут ли учёт по-прежнему в чатах или в старой Jira.

Self-hosted

Plane стоит на сервере компании или казахстанского хостера. Данные остаются в стране, но обновления и резервные копии становятся вашей ответственностью.

Docker и Kubernetes

Стандартные инструменты для установки и запуска программ на серверах в виде готовых контейнеров. Через них Plane разворачивают на собственном сервере.