Когда в корпоративном трекере несколько десятков проектов, миграцию еще можно представить как техническую операцию с понятным началом и концом. У «Ростелекома» масштаб другой — тысячи проектов, миллионы задач, собственные автоматизации, плагины, связи между сущностями и рабочие процессы, которые годами подстраивались под команды. Все это нужно было перенести с Jira, Confluence и Trello на российскую платформу так, чтобы разработчики продолжили действовать практически в привычном ритме. В качестве новой системы выбрали «Ягу» от ИТ-экосистемы «Лукоморье».
Сейчас на платформу уже перенесены более 7000 пользователей, свыше 9000 проектов и более 1,5 млн задач. До конца 2026 года планируется мигрировать еще около миллиона задач. Параллельно начался перенос корпоративной базы знаний из Confluence.
Мигратор и сама «Яга» развивались одновременно — каждый очередной проект приносил собственный набор настроек, исключений и сценариев Jira, которых до этого никто не встречал. Команда переносила данные, дорабатывала инструменты миграции, выпускала новые функции в платформе и снова возвращалась к следующей партии проектов.
За время работы появилось более 100 пользовательских историй, связанных непосредственно с импортозамещением, и около 200 историй по развитию мигратора.
От Jira и Confluence зависели уже не отдельные команды
До начала проекта Jira, Confluence и Trello были встроены в повседневную работу «Ростелекома». В трекере жили проекты и задачи, команды планировали спринты и релизы, использовали собственные схемы прав, автоматизации и дополнительные плагины. В Confluence хранилась документация и накопленная за годы база знаний, поэтому обычной замены интерфейса было недостаточно. За каждым проектом стояла своя конфигурация, а иногда и привычки конкретной команды, закрепленные в настройках системы.
При переносе требовалось сохранить задачи, историю изменений, вложения, релизы, спринты, связи и пользовательские сценарии. Отдельная часть работы касалась автоматизаций и интеграций с внутренними сервисами «Ростелекома».
Масштаб быстро превратил миграцию в самостоятельный продуктовый проект. Прежде чем переносить очередное пространство, команда анализировала его структуру и определяла, какие сущности и настройки придется воспроизвести в «Яге».
Сейчас интенсивность использования новой системы уже можно оценивать по статистике. Только за один из последних месяцев сотрудники создали в ней более 22 тыс. задач.
Как выбирали замену
Перед командой стояла задача собрать единое рабочее пространство для разработки и проектной работы на российском ПО из реестра отечественных решений.
Для замены Jira используется модуль «Яга Задачи». В нем есть проекты, задачи, канбан-доски, спринты, релизы, диаграммы Ганта, роли, автоматизации и API для интеграции с другими корпоративными системами.
Confluence постепенно заменяет «Яга Статьи». Модуль используется как корпоративная база знаний, где можно хранить проектную и техническую документацию, совместно редактировать материалы и связывать их с задачами.
Для большой компании важным оказалось и то, что оба инструмента существуют в рамках одной платформы. Пользователь может работать с задачей и связанной с ней документацией без постоянного перехода между отдельными системами.
По оценке команды проекта, сейчас «Яга» закрывает около 90–95% основных сценариев, которые используются внутри «Ростелекома». Заодно в платформе воспроизвели возможности примерно 20 внешних плагинов Jira, которые раньше приходилось закупать отдельно.
При этом «Яга» не просто воспроизводит привычные сценарии Jira, а предлагает полноценную среду управления проектами и командной работой: от гибкой настройки процессов, ролей и полей до канбан-досок, спринтов, релизов, диаграмм Ганта и учёта трудозатрат. Благодаря интеграции с «Яга.Статьи» задачи и проектная документация работают в едином пространстве, позволяя заменить связку Jira и Confluence.
Переносить пришлось не Jira вообще, а тысячи разных Jira
Главная сложность открылась уже в процессе — при одинаковом названии системы реальные проекты внутри Jira отличались. Одна команда использовала стандартную доску и несколько статусов. Другая строила вокруг Jira сложную систему автоматизаций, собственных полей, скриптов и связей. Третья подключала внешние плагины и меняет логику жизненного цикла задач под внутренние процессы. Из-за этого универсального сценария вида «экспортировали данные, импортировали и забыли» здесь не было.
Для каждого проекта команда сначала изучала конфигурацию. После этого определяла набор сущностей для переноса и проверяла, поддерживает ли их текущая версия мигратора.
Сам технический запуск был устроен компактно. Через Swagger задавались параметры проекта и отмечались элементы, которые нужно перенести: задачи, релизы, вложения, скрипты, экраны, спринты, историю и другие сущности. Затем запускали job, который перекладывал данные из структуры Jira в структуру «Яги».
Если смотреть только на этот этап, один проект в среднем можно перенести за рабочий день. Настоящая работа начинается после него — данные нужно проверить, автоматизации восстановить, процессы настроить, а пользователям убедиться, что привычные сценарии действительно работают. В простом проекте это занимает несколько дней. В сложном — несколько недель.
Миграция стала источником требований к самой платформе
Во многих проектах импортозамещения сначала создают продукт, а затем начинают перенос пользователей. Здесь граница между этапами стерлась. «Яга» продолжала развиваться непосредственно во время миграции — команда выпускала примерно по 10–15 новых функций в месяц. Часть возможностей сначала появлялась в минимальном варианте, чтобы очередная группа пользователей могла перейти на платформу, после чего функциональность дорабатывали.
Похожим образом развивался и «Ростелеком». Первые версии поддерживали относительно простые сущности. Следующие проекты приносили новые требования, и в инструменте появлялся перенос релизов, спринтов, связей и более сложных конфигураций.
Всего за время проекта реализовали около 200 пользовательских историй, связанных с мигратором, и еще более 100 историй, появившихся из задач импортозамещения в самой «Яге».
Такая схема оказалась полезна из-за того, что требования к платформе формировались на живых данных крупной компании. Если функции не хватало, это становилось понятно не из абстрактного списка возможностей Jira, а в конкретном рабочем процессе. Так постепенно появился набор сценариев, который действительно требуется тысячам сотрудников «Ростелекома».
Что поменялось для пользователей
По обратной связи сотрудников, одним из заметных изменений стала большая самостоятельность в настройках проекта. Ряд операций, для которых раньше приходилось обращаться к администратору, владельцы проектов теперь могут выполнять самостоятельно. Это касается прав пользователей, создания дополнительных досок, настройки их логики и отображения, изменения атрибутов карточек и статусов. Проще стало и добавление сотрудников в проекты.
Для команд, которые одновременно работают с документацией и задачами, отдельным плюсом стало объединение модулей «Задачи» и «Статьи» в одном интерфейсе.
При этом одной из главных проверок для проекта оставался обычный рабочий день после миграции. По отзывам пользователей, переход не заставил команды перестраивать базовые процессы: ключевые сценарии, с которыми они работали в Jira, в «Яге» сохранились.
Для проекта такого масштаба эти отзывы важны еще и потому, что новая система внедряется не в изолированном подразделении. Через нее уже работают более 7000 человек.
К чему пришли
На текущем этапе на «Ягу» перенесены свыше 9000 проектов и более 1,5 млн задач. Платформой пользуются более 7000 сотрудников. До конца года объем миграции должен увеличиться еще примерно на миллион задач.
Отдельное направление сейчас связано с Confluence. Перенос базы знаний в «Яга Статьи» уже начался, поэтому следующая часть проекта затрагивает накопленные документы и связанные с ними процессы.
Внутри самой платформы миграция оставила еще один результат. «Яга» научилась воспроизводить около 90–95% основных рабочих сценариев «Ростелекома», а функции примерно двух десятков внешних Jira-плагинов теперь входят в собственный контур.
«Платформа «Яга» стала стратегическим ответом на потребность российского бизнеса в независимых инструментах управления разработкой. Мы гордимся, что «Ростелеком» доверил нам миграцию своих ключевых процессов. Сегодня «Яга» успешно замещает Atlassian в одном из крупнейших телеком-холдингов страны».
Арсен Благов, генеральный директор ИТ-экосистемы «Лукоморье»
Что показал проект
История «Ростелекома» показала, почему крупная миграция с Jira редко сводится к сравнению таблиц функций двух продуктов. За годы эксплуатации корпоративный трекер успевает обрасти собственными правилами и исключениями, и именно они оказываются самой сложной частью переноса.
При масштабе в миллионы задач мигратор приходится развивать почти так же внимательно, как сам продукт. Один проект приносит новый тип связи, следующий — нестандартную автоматизацию, третий — сценарий из внешнего плагина. Постепенно из этих частных случаев складывается платформа, приспособленная к реальной корпоративной разработке.
В случае «Ростелекома» этот процесс еще продолжается. Полтора миллиона перенесенных задач здесь скорее промежуточная отметка — впереди еще около миллиона и отдельная большая работа с базой знаний. При этом тысячи проектов продолжают жить после переезда, а новая система развивается на их реальных требования.