Jira ушла, а задачи остались: как оценить объем данных для миграции и не потерять бизнес

С марта 2026 года Atlassian прекратил продажи новых лицензий Data Center. Доступ к облачным сервисам для российских компаний закрыт, обновлений и поддержки нет. Но, как показывают исследования, 70 % компаний продолжают работать в неподдерживаемых версиях Jira.

Это не безрассудство. Это рациональная реакция на реальную сложность перехода, где цена ошибки высока: потеря бизнес-истории, простой команд, сорванные сроки. 

О том, как мигрировать без потерь и начать работать в новой системе, рассказываем в статье. 

Оценка данных — это не про технику, а про бизнес

Переход с Jira на другую платформу, дело действительно серьезное. Потому что Jira — это не просто трекер задач. Это цифровой слепок бизнес-процессов компании. В ней хранятся:

1. История принятия решений: каждый комментарий, переход между статусами, связь между эпиками и сабтасками.
2. Институциональная память: годы накопленных знаний о том, как устроена разработка, тестирование, релизы, согласования.
3. Метрики и KPI: данные о скорости команд, времени выполнения задач, прогнозах сроков.

И это лишь вершина айсберга. За годы работы Jira обрастает настройками: меняются руководители, добавляются поля, устаревают workflow, никто не чистит архивы. В итоге система превращается в «чёрный ящик» и никто уже не помнит, зачем нужна половина настроек.

Поэтому просто взять и скопировать всё подряд не получится. Без аудита вы перенесете в новую среду не только нужные данные, но и накопившийся хаос. Исправлять его потом будет в разы сложнее и дороже, чем разобраться до старта.

С чего начинается оценка объема данных: пошаговый аудит

Чтобы не тащить хаос в новую систему, перед миграцией важно понять: что именно нужно переносить. 

Шаг 1. Инвентаризация проектов и задач

Для начала разделите проекты на активные и архивные. В активных оцените объем данных: количество задач, пользовательских полей, вложений. Учитывайте также комментарии, связи между задачами и настройки workflow. 

Шаг 2. Аудит workflow и бизнес-логики

Это самый сложный и самый важный этап. Workflow в Jira — это не просто набор статусов. Это:

1. Правила переходов между статусами (кто, когда и при каких условиях может перевести задачу).
2. Скрипты и автоматизации (часто написанные под конкретные нужды).
3. Интеграции с внешними системами (CI/CD, системы тестирования, чаты, документооборот).

И здесь кроется главная ловушка. В Jira настройки workflow и сами данные (задачи, комментарии, вложения) хранятся раздельно. Поэтому при переносе проекта в новую систему может случится так, что задача восстановлена, но логика движения потеряна. Выпадающие списки окажутся пустыми, переходы между статусами перестанут работать, согласования не дойдут до адресатов. 

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

Не менее опасны пользовательские поля, особенно если они привязаны к конкретным типам задач. При переносе они могут стать недоступными. Если вовремя это не проверить, можно потерять важную информацию. 

В результате аудита должен получиться не список функций, а список четких требований к новой системе. И здесь критически важно понять: что по итогу вам нужно. Точный аналог Jira или инструмент, который решает ваши задачи, но, возможно, другим способом? Ответ на этот вопрос определит не только выбор платформы, но и объем миграционных работ.

Шаг 3. Оценка пользователей и прав доступа

В крупных организациях Jira может обслуживать тысячи пользователей со сложной матрицей прав. Перенос такой структуры требует отдельного подхода, а именно оценки:

1. количества активных пользователей;
2. групп и ролей;
3. настроек видимости проектов и задач;
4. персональных дашбордов и фильтров.

Если в вашей Jira тысячи пользователей, подготовку к миграции нужно начинать не за месяц, а как минимум за три. И делать это лучше с привлечением специалистов по миграции. Ошибки обойдутся дороже. 

Шаг 4. Анализ «мертвого груза» и очистка данных

Аудит почти гарантированно покажет, что часть данных вообще не нужна. До миграции стоит удалить:

1. Дублирующиеся или устаревшие пользовательские поля.
2. Задачи, закрытые более трёх лет назад и не имеющие бизнес-ценности.
3. Неиспользуемые workflow, которые никто не поддерживает.

В новой системе должно остаться только то, что реально работает на бизнес. 

Реальные сроки миграции с Jira и риски

По данным К2Тех, 53% компаний закладывают на миграцию 1–2 года, 28% — более двух лет. Эти цифры говорят о том, что компании осознают сложность перехода. 

Но даже при таких оценках реальный объём работ часто оказывается больше. Потому что большинство компаний недооценивают, сколько данных накопилось за годы. А когда в процессе выясняется, что нужно перенести 60 проектов, 120 000 задач и 300 пользовательских полей, проект стопорится. И за этим стоят вполне конкретные риски:

1. Команды простаивают: если критичные данные не перенесены вовремя, разработка останавливается.
2. Данные теряются: неправильная конвертация может «порвать» связи между задачами.
3. Сроки срываются: переезд затягивается, бюджеты растут.

Как подойти к миграции системно: пошаговый план

Миграцию с Jira следует проводить в несколько этапов:

Этап 0. Аудит и очистка: анализ текущей системы, инвентаризация данных, удаление «мёртвого груза». Именно на этом этапе проводится детальная оценка объёма данных.

Этап 1. Выбор платформы: на основе результатов аудита определите, какой инструмент лучше всего соответствует вашим требованиям.

Этап 2. Тестовая миграция: выберите один проект и перенесите его в новую систему. Проверьте целостность данных: все ли задачи, комментарии и вложения на месте. Убедитесь, что workflow работают, а интеграции не сломались. 

Этап 3. Валидация: привлеките ключевых пользователей, получите обратную связь, выявите проблемы до основного перехода.

Этап 4. Поэтапный запуск: переносите проекты постепенно, а не все сразу.

На что обратить внимание при выборе новой платформы 

При выборе альтернативы Jira в первую очередь нужно смотреть на архитектуру, логику работы и возможности масштабирования. Хорошая платформа должна:

1. Поддерживать Agile и Scrum. Без этого команды не смогут работать привычным способом.
2. Работать с бизнес-процессами. Статусы задач должны меняться автоматически по заданной логике, а не вручную.
3. Иметь API и инструменты кастомизации. Чтобы можно было адаптировать систему под свои нужды и интегрировать с другими сервисами.
4. Предлагать импорт данных из Jira. Готовый коннектор сильно упрощает и ускоряет перенос.
5. Разрешать поэтапную миграцию. Чтобы можно было запустить пилотный проект и только потом переносить всё остальное.
6. Предоставлять русскоязычную поддержку и документацию. Это критично для оперативного решения проблем.

И этим требованиям сегодня соответствует целый ряд российских решений:

Digital Q.Tasks&Teams («Диасофт») — платформа, полностью заменяющая Jira. Поддерживает методологию Agile и Scrum Guide. С октября 2025 года доступна бесплатная версия на 20 пользователей.

Kaiten — канбан-платформа с поддержкой автоматического импорта из Jira. Есть гибкая настройка процессов, модульная система (автоматизация, диаграмма Ганта, управление ресурсами).

Яндекс Трекер — облачная система управления проектами и задачами от Яндекса. Есть возможность миграции из Jira, поддержка Scrum и Kanban. Подходит для команд, которым не требуются сложные интеграции и on-premise развертывание.

SimpleOne SDLC — российская платформа для управления продуктовой разработкой. Есть опыт миграции с Jira и Trello (например, компания vStack). Включена в реестр российского ПО.

Но какую бы платформу вы ни выбрали, перед покупкой запросите тестовый доступ, загрузите свои задачи, посмотрите, как переносятся данные и работают процессы. Только так вы поймете, подходит ли система вам.