Допустим, ваш Jira-инстанс прожил шесть лет. Через него прошли десятки тысяч задач, сотни кастомных полей и десятки плагинов. И вот приходит время переезда на новую платформу.
DevOps-команда поднимает тестовый стенд, выполняет пробную миграцию. На первый взгляд всё выглядит отлично: задачи на месте, проекты открываются, пользователи могут работать. Но после перехода в промышленную среду начинают всплывать проблемы, которых на тестовом контуре никто не заметил. Где-то пропадают комментарии, где-то не восстанавливаются связи между задачами, а в одном из проектов оказывается недоступна история согласований, необходимая для аудита.
Почему так происходит, если всё было проверено? Потому что тестовая среда не отражает боевой хаос. Она чистая и предсказуемая, в ней нет шестилетней истории изменений, кастомных скриптов и забытых интеграций. А значит, миграция – это не техническая операция, а стратегический рефакторинг. Если подходить к ней как к простому копированию, вы перенесете не только данные, но и весь накопленный хаос, а часть критической информации вовсе потеряете навсегда.
Именно поэтому важно правильно выбрать способ перехода – от этого зависит, что вы сохраните, а что потеряете.
Способы миграции: что выбрать и какие ограничения учитывать
В Jira задачи, комментарии, вложения, связи между задачами, права доступа и настройки workflow существуют как взаимосвязанные сущности. При миграции каждая из них требует отдельной обработки. Поэтому выбор способа переноса определяет не только скорость работ, но и то, какие данные удастся сохранить без потерь.
Важно сразу разделить подходы в зависимости от типа Jira:
- Jira Server / Data Center – у вас есть доступ к БД и файловой системе. Можно использовать бэкапы, прямое копирование `data` и сторонние утилиты.
- Jira Cloud – только API. Никаких бэкапов в привычном смысле нет. Миграция выполняется исключительно через REST или GraphQL, что накладывает жесткие ограничения по скорости (throttling) и объему данных за один запрос.
Это принципиальный момент, который влияет на всё дальнейшее.
REST API: гибкость, которая требует дисциплины
REST API Jira предоставляет доступ к данным и позволяет выполнять миграцию поэтапно, не останавливая работу системы. Здесь важно понимать: API – это инструмент для выгрузки данных, а не готовая кнопка "перенести всё". Любой перенос потребует разработки скриптов или использования специализированных инструментов.
Какие данные доступны через API:
- Задачи (Issues) со всеми полями.
- Комментарии – возвращаются в теле задачи.
- Вложения – доступны для скачивания по отдельным ссылкам.
- Связи между задачами (Issue Links) – при условии, что вы правильно сопоставите ID в целевой системе.
Что не переносится автоматически и требует отдельной обработки:
- История изменений (changelog) – не входит в стандартный ответ API при получении задачи. Её нужно запрашивать дополнительно. Учитывайте пагинацию: история одной задачи может содержать тысячи записей.
- Workflow-схемы, экраны, схемы прав – требуют маппинга статусов, пользователей и групп, так как идентификаторы объектов в новой системе будут другими. Процесс можно автоматизировать скриптами, но он остается трудоемким и требует тщательной проверки.
- Правила автоматизации и скрипты ScriptRunner – переносятся только на уровне логики. Скрипты ScriptRunner завязаны на внутренние классы Jira и при переходе на другую платформу требуют полной переработки. Закладывайте это в план как отдельную задачу.
Связи между объектами. Типичный сценарий: задачи импортируются отдельно, вложения – отдельно. Но при импорте вложение не сопоставляется с новым ID задачи в целевой системе. На небольшом тестовом контуре это незаметно, а на боевой базе с тысячами задач пользователи открывают карточки и не находят файлов. Единственный надежный способ избежать этого – заранее построить таблицу соответствия ID (source_id – target_id) и использовать её на всех этапах импорта. Это требует отдельного скриптового слоя.
Ограничения API. Дополнительный риск для Jira Cloud – жёсткие лимиты на количество запросов. Выгрузить 50 000 задач одним запросом невозможно. Придётся работать с пагинацией, учитывать лимиты и делать повторные попытки при сбоях. В результате миграция, которая в теории могла бы занять часы, растягивается на дни. Закладывайте это в план на этапе оценки сроков.
CSV: быстро, но с подводными камнями
Если REST API требует скриптов и программирования, то CSV самый простой способ выгрузки с технической точки зрения. Он позволяет быстро получить текущий срез задач и не требует сложной настройки. Однако это моментальный снимок состояния «здесь и сейчас», а не полноценный архив проекта.
Что доступно для выгрузки:
-
Текущее состояние задачи (поля и их значения).
Что не выгружается:
- История изменений.
- Вложения (выгружаются только ссылки, которые после переноса станут битыми).
- Права доступа.
- Автоматизации.
- Комментарии – если не добавить их отдельным полем, при импорте потеряется авторство и время создания.
CSV-экспорт – это ручная операция. Вы инициируете выгрузку через интерфейс Jira, получаете файл и затем импортируете его в целевую систему. Никакой автоматизации в этом процессе нет.
Но главный риск в другом: при импорте CSV в целевую систему автоматически запускаются пост-функции рабочих процессов (post-functions). Это может привести к неожиданным последствиям: некоторые поля в импортированных задачах будут очищены или перезаписаны без уведомления. Например, поле «Ответственный» может быть переопределено правилом назначения по умолчанию, а все вручную заполненные значения будут утеряны.
Вывод: CSV подходит только для ограниченного круга задач: перенос справочников, разовый экспорт данных для анализа, проекты, где не важны история и вложения.
Для полноценной замены Jira этот метод неприменим.
Но даже при идеально выбранном инструменте часть данных остается в зоне риска.
Какие данные находятся в зоне риска
Есть несколько категорий данных, которые уязвимы при любом способе переноса, если специально не контролировать процесс.
История изменений (Changelog)
Перенос истории изменений – одна из самых сложных задач при миграции. Причина кроется в особенностях REST API: changelog не переносится автоматически, а способ его выгрузки зависит от версии Jira и объёма данных.
Однако даже после успешной выгрузки остаются риски, связанные с импортом. Самый частый из них – потеря авторства и временных меток. Эти данные нужно правильно сопоставить, особенно если в целевой системе используются другие часовые пояса. Иначе аудиторский след будет испорчен.
Кроме того, есть еще одна ловушка: если до начала миграции удалить кастомные поля, записи истории, ссылающиеся на них, при импорте исчезнут бесследно – восстановить их будет невозможно. Поэтому аудит полей нужно проводить до удаления, а не после.
И наконец, обязательно проверяйте результат. После тестовой миграции выберите 10-20 задач с богатой историей и сравните количество записей в changelog до и после. Расхождение более 5% – повод разбираться в причинах.
Связи между задачами
Еще одна зона риска – связи между задачами. Родительские задачи, подзадачи, зависимости и блокировки не всегда восстанавливаются автоматически. Их необходимо корректно сопоставлять вручную. Если импортировать задачи пачками, а связи восстанавливать позже, часть зависимостей может быть потеряна.
Особенно внимательно стоит проверять направленные связи (Issue Links). В Jira связь «блокирует» отличается от связи «заблокирована». Если при миграции перепутать направление, система формально сохранит связь, но ее смысл изменится. В результате разработчики увидят искаженную картину зависимостей, что неизбежно повлияет на планирование и приоритизацию задач.
После миграции выполните запрос по типу связи "is blocked by" и сравните результат с исходной системой. Расхождение недопустимо.
На что еще обратить при миграции с Jira
В Jira есть объекты, о которых вспоминают только в тот момент, когда они ломаются. Вот чек-лист зон, требующих обязательного аудита перед любым переносом.
Workflow schemes (Схемы рабочих процессов)
Если вы переносите только задачи (issues) через API, в целевой системе останется лишь текущий статус каждой задачи. История переходов между статусами не сохранится. Вы потеряете аналитику по времени в статусах, которая лежит в основе управления процессами.
Если вы переносите workflow-схемы целиком, переходы могут сохраниться. С одной стороны, это удобно – не нужно настраивать всё заново. С другой – без маппинга внутренних ID ничего не выйдет. Потому что в Jira переходы и статусы привязаны к числовым ID, которые уникальны в пределах инстанса, а в новой системе они будут другими.
Прежде чем выбирать способ, ответьте на вопрос: «Что для нас важнее – сохранить историю переходов или сэкономить время на настройке, перенеся только задачи?» От этого зависит, будете ли вы переносить схемы как есть (с риском поломки) или настраивать их заново.
Custom fields (Пользовательские поля)
В крупных инстансах значительная часть кастомных полей не используется в фильтрах и отчетах более года. По статистике, это может быть более половины всех полей. Они создавались под давно закрытые задачи, но все еще отображаются на экранах, замедляют работу и создают иллюзию сложности.
Здесь нужен баланс:
- Если вы переносите все поля, вы переносите этот шум в новую систему.
- Если вы удаляете поля до миграции, вы рискуете потерять историю изменений по этим полям.
Решение достигается только через аудит использования каждого поля.
Аудит можно провести через SQL-запрос (для Server/DC) или через REST API (для Cloud). Также существуют плагины, которые автоматизируют этот процесс.
Screens и Permission schemes (Экраны и схемы прав)
Схемы экранов. В Jira экраны привязаны к типам задач и проектам. При миграции эта привязка может сбиться. Например, пользователь открывает задачу, а вместо привычных полей видит пустую форму. Причина: в новой системе экран не сопоставлен с типом задачи.
Схемы прав. Это отдельная история. Права доступа в Jira привязаны к ID пользователей и групп. При переносе в новую систему эти ID меняются. Если не сделать маппинг пользователей и групп (это уже не про статусы, а про людей), доступ к проектам получат не те сотрудники или не получат его вовсе. Это особенно критично для проектов с ограниченным доступом.
Заранее подготовьте маппинг пользователей и групп, а также проверьте привязку экранов к типам задач на тестовом стенде.
Automation Rules и ScriptRunner (Правила автоматизации и ScriptRunner)
Automation Rules. Правила автоматизации ссылаются на конкретные ID проектов, статусов, пользователей и полей. В новой системе эти ID будут другими. Если перенести правила «как есть», они продолжат ссылаться на старые ID и перестанут работать.
ScriptRunner. Скрипты и обработчики событий этого плагина часто завязаны на внутренние Java-классы Jira, которые меняются от версии к версии и могут сломаться даже при переходе на новую версию самой Jira. Поэтому при миграции на стороннюю платформу их, как правило, нужно полностью переписывать. И это будет один из самых трудоемких этапов перехода.
Webhooks, интеграции и плагины
Webhooks и интеграции. Внешние системы (CI/CD, мониторинг, служба поддержки) «помнят» старый адрес Jira и старые токены. А после переезда и адрес, и токены изменятся. Если не обновить их заранее, интеграции перестанут работать.
Плагины. Плагины для учёта времени (Tempo) и управления активами (Insight) не переносятся стандартными средствами. Их нужно заменять аналогами или пересматривать процессы. Проверьте заранее, есть ли в целевой системе аналоги этих плагинов, и спланируйте миграцию данных из них отдельно.
Как провести миграцию правильно: дорожная карта
Миграция – это возможность для рефакторинга
За годы использования Jira инстанс неизбежно обрастает техническим долгом: архивные проекты, устаревшие поля, забытые автоматизации – всё это можно назвать цифровым мусором.
Миграция дает отличный повод навести порядок. Удалить неиспользуемое, объединить дублирующееся, сократить лишнее. В результате вы перенесете не тонны мусора, а чистую систему. Переезд пройдет быстрее, а команды получат простую и понятную среду.
И здесь не обязательно всё делать своими силами. Многие российские вендоры предлагают готовые инструменты миграции, которые автоматизируют перенос данных и сокращают время перехода. Например, при переходе с Jira на Digital Q.PM от «Диасофт» платформа позволяет не просто перенести задачи, а сразу настроить управление портфелями, бюджетированием и ресурсным планированием. Вместо того чтобы тратить время на ручной перенос и доработки, команда получает готовую инфраструктуру для комплексного управления проектами.
Комментарии