Представьте: команда из 80 человек несколько лет живёт в Jira. Доски, спринты, кастомные поля, автоматизации на Groovy, сотни вложений, тысячи ссылок, разлетевшихся по корпоративным вики и письмам. 

И вот в один прекрасный день приходит задача: «Переезжаем». Дедлайн — три месяца. При этом на старте никто не знает, что в системе накопилось за годы: десятки автоматизаций, половина из которых создавалась под задачи, которых уже нет.

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

Всем привет, я Артём Герасимов, владелец продукта SimpleOne SDLC. В статье о том, почему технически успешная миграция и счастливая команда — это два разных проекта.

Отдельную благодарность за помощь в написании статьи выражаю автору SimpleOne Панфиловой Яне.

Данные — не проблема

Когда смотришь на Jira снаружи — это задачи, поля, статусы, комментарии. Кажется, что это просто таблица. И в каком-то смысле это правда: Jira хранит всё в реляционной базе. Отсюда ощущение, что выгрузить и загрузить — дело техники.

Так и есть, но только для данных. Вот, что переносится без особых проблем:

Задачи и их поля

Названия, описания, приоритеты, кастомные поля. Всё это живёт в таблицах и мигрирует через CSV Import или API. CSV быстрее для массовых данных, API — гибче, когда нужно вытащить то, что Jira не отдаёт стандартным экспортом.

Структура проектов

Иерархия, типы задач, статусы. Переносится, но требует ручного маппинга: поле «Story Points» в Jira и аналогичное поле в другой системе — не одно и то же автоматически.

Вложения

Технически переносимы, хотя здесь возникают нюансы в зависимости от объёма и способа хранения.

История изменений

Переносится, но часто теряет читаемость: кто и что поменял — видно, а вот контекст («почему») уже нет.

Что не переедет, как вы ожидаете

И именно это команды обычно понимают уже после старта миграции.

ScriptRunner и Automation Rules

В Jira автоматизации написаны на Groovy, но в большинстве альтернативных систем — другой язык (например, JavaScript). Перенести автоматизацию «болт в болт» невозможно. Её нужно переписывать. Полностью. 

Типичный разговор на этом этапе: 

— Сколько у нас автоматизаций? 

— Ну штук двадцать, наверное. — [открывает Jira] …здесь сорок семь. 

— Что? 

— Сорок семь. 

И вот эта называется «старый костыль 2021 не трогать»

Это не катастрофа, но это не «перенос» — это разработка заново. Хорошая новость: если логика была здравой, она воспроизводится. Плохая: это занимает время, которое никто не закладывает в план.

URL-адреса и внешние ссылки

Годами команда вставляла ссылки на конкретные задачи Jira — в Confluence, в корпоративный мессенджер, в письма, в регламенты. После миграции все эти ссылки ведут в никуда. Либо вы делаете отдельный проксирующий сервис для переадресации, либо принимаете, что часть внутреннего контекста просто умерла. Это не техническая проблема — это проблема организационной памяти.

Пользовательские дашборды и фильтры

Каждый аналитик и тимлид годами строил свои виды. Это не данные — это навыки работы с системой, кристаллизованные в настройках. 

— Где мой дашборд? 

— Его нет, нужно пересобрать в новой системе. 

— Окей, а как он выглядел? 

— Ну там были какие-то графики. 

— Какие? 

— Не помню. Но они были важные.

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

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

Данные переехали. Команда — нет

Вот парадокс, который я видел не раз: технически всё прошло отлично — данные на месте, автоматизации переписаны, дашборды воссозданы. А команда всё равно несчастна ещё месяца три после переезда.

Потому что люди работали не с данными — они работали с интерфейсом, с конкретными кликами, с мышечной памятью. «Я знаю, куда нажимать» — это и есть ценность зрелой системы. И это не переносится никаким скриптом.

Как сделать переезд менее болезненным

Аудит до миграции, а не во время

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

Типичная картина: заходишь в список полей — их 60. Начинаешь спрашивать команду, что из этого живое. Оказывается — от силы 20. Остальное копилось годами по принципу «а вдруг пригодится».

Лучше разобраться с этим до старта — не тащите мусор в новую систему.

Инвентаризация автоматизаций

Выпишите все Automation Rules и скрипты. Оцените каждый: переписать, упростить или выбросить. Часть из них решала проблемы, которых в новой системе просто не существует.

— Вот эта автоматизация 

— она вообще зачем? 

— Не знаю, её Вася писал. 

— Вася здесь ещё работает? 

— Нет, он ушёл в январе.

Таких записей обычно треть. Их можно просто удалить.

Карта внешних ссылок

Где и как на Jira ссылаются снаружи? В Confluence, в регламентах, в старых письмах. После миграции всё это превращается в битые ссылки, и никто не знает, что за ними было.

Если ссылок много — заложите время на проксирующий сервис или на ручное обновление. Не надейтесь, что «потом разберёмся» — «потом» растягивается на год, и контекст просто умирает.

Параллельный запуск хотя бы на месяц

Да, это двойная нагрузка. Но именно в этот период всплывают все «ой, а это мы не перенесли».

Это первое, что режут когда поджимают сроки. Почти всегда об этом жалеют — именно тогда выясняется, что какой-то отчёт или интеграция вообще не были учтены в плане. А не учитывают всегда.

Обучение — не как опция, а как часть проекта

Новый интерфейс — это новая мышечная память. Заложите время. Особенно для тех, кто работает в системе каждый день.

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

Резюме

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

***

А у вас был опыт миграции с Jira или другого трекера? Что оказалось самым болезненным — техническая часть или человеческая?