Представьте: команда из 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 или другого трекера? Что оказалось самым болезненным — техническая часть или человеческая?