Россия входила в тройку стран по числу серверных установок Atlassian — компании намеренно брали серверные лицензии, чтобы данные оставались внутри контура. Когда вендор ушёл из России в октябре 2022 года, судьба пользователей разошлась в зависимости от типа продукта.
Пользователи облачных версий — Jira Cloud, Confluence Cloud, Trello — получили уведомления об отключении аккаунтов ещё в августе 2023 года. Серверные инсталляции оказались в другом положении: систему снаружи не заблокируешь, но глобальная поддержка Server-продуктов прекратилась 15 февраля 2024 года — система осталась без обновлений, патчей безопасности и технической помощи. Часть компаний успела зафиксировать лицензию до дедлайна и продолжила работать именно в таком режиме. Другие перешли на серые ключи — физически встречались с людьми, которые передавали активационные коды, лишь бы не останавливать сотни проектов в Jira. Ещё часть просто перестала платить и работает как есть.
Отдельную группу давления создаёт глобальный EOL для Data Center: с марта 2026 года Atlassian прекратил продажу новых лицензий Data Center, в 2028 году закроет продление существующих, а полная поддержка завершится в 2029-м. Для российских компаний, которые после ухода вендора перешли именно на Data Center как на «безопасную» замену Server, это означает, что мигрировать всё таки придётся.
Независимо от сценария, все компании объединяет одно: выбор замены откладывается, потому что смотреть на список из десяти аналогов и выбирать из него — психологически невозможно. Список не даёт ответа, он даёт иллюзию работы над проблемой. Эта статья про другое: как использовать вынужденный переход, чтобы выйти из него с процессами лучше, чем они были до ухода Atlassian.
Сегодня об этом рассказывает Евгений Котухов, технологический партнер SimpleOne, ITSM/ITAM-эксперт.
Ты замещаешь не Jira, а работу
Прежде чем смотреть на рынок, полезно ответить на вопрос: какую часть Atlassian вы реально эксплуатировали? По моему опыту внедрений, большинство компаний использовали стек примерно так: Jira — для управления задачами и разработкой, доски, карточки, спринты; Confluence — как база знаний по проектам и командам. Trello встречался там, где нужна была просто доска без лишнего. Bitbucket и Bamboo — у тех, кто строил CI/CD внутри экосистемы Atlassian, но таких компаний среди российских заказчиков было заметно меньше.
Jira Service Management — у тех, кто строил на Atlassian ещё и техподдержку: заявки, инциденты, портал самообслуживания. Для них задача сложнее, потому что нужно пересобрать сразу разработку, знания и поддержку, которые жили в одной экосистеме. При этом, как я считаю, Jira Service Desk на момент ухода вендора с рынка уступал специализированным ITSM-решениям по большинству параметров. Значит, замена в этой части — не задача воспроизвести то, что было, а задача выбрать то, что изначально должно было стоять на этом месте
Миграция с Jira на SimpleOne: опыт компании АЭРОДИСК
Продуктовые и разработческие команды привязаны к Jira сильнее всего: десятки и сотни проектов, история задач, связи между тикетами, вложения. Именно они чаще всего оказывались в ситуации с серыми ключами, потому что слишком много накоплено, чтобы просто выключить и начать заново. Для них переход требует внятного ответа на вопрос о глубине миграции: переедет ли история, сохранятся ли связи между задачами, что будет с вложениями.
Поэтому, прежде чем двигаться дальше, зафиксируйте свой реальный стек: какие инструменты из экосистемы Atlassian используются активно, какие — формально, и какие процессы на них завязаны.
Сначала цели, потом инструменты
Компании, которые уже прошли через выбор замены, в большинстве случаев спотыкались на одном и том же месте: шли смотреть рынок до того, как сформулировали, чего хотят достичь. Вендор приходил с презентацией, рассказывал про возможности системы, и дальше выбор строился вокруг того, насколько убедительно звучал маркетинг. Измеримых критериев успеха не было — значит, не было и способа сравнивать.
Цели в этом случае — это конкретные показатели, которые можно зафиксировать до внедрения и проверить после. Например:
Сократить среднее время закрытия инцидента с 4 часов до 2. Поднять процент заявок, закрытых в срок, с 60% до 85%.
Запустить портал самообслуживания, через который сотрудники подают заявки без звонков в поддержку.
Подключить к единой системе не только ИТ, но и HR, юристов, финансистов — то, что называется ESM, Enterprise Service Management. Тут особенно показательно: Atlassian для этого не был приспособлен, и компании, у которых такая потребность была, всё равно держали рядом что-то ещё.
То есть миграция с одного решения на другое — это уникальная возможность сделать лучше, чем было до этого. Цели, которые бизнес поставит перед выбором замены, могут стать проводником к более эффективным процессам и экономии денег.
После того как цели зафиксированы, появляется второй фильтр для выбора решения — отсекающие критерии, которые сужают список вариантов независимо от функциональности. Для компаний из перечня КИИ или с госучастием действует запрет на иностранное ПО (Указ Президента №166), а используемое решение должно присутствовать в реестре отечественного ПО (ПП №1236). Требования 152-ФЗ и политика хранения данных определяют, возможно ли облачное размещение или нужен только on-prem. Многим интересно, можно ли перенести накопленные за годы работы данные или они потеряются. Наконец, существующие интеграции: с какими системами нынешний стек связан и насколько болезненно их перестраивать.
Критерий | Когда становится жёстким |
Реестр ПО | КИИ, госучастие, финансовый сектор |
On-prem размещение | 152-ФЗ, внутренняя политика по данным |
Глубина миграции | Более 50 активных проектов в Jira |
Интеграции | Связка с ERP, AD, CI/CD-пайплайнами |
ESM-расширение | Планируется подключение не-ИТ подразделений |
Критерии из этой таблицы не ранжируются по важности — они либо выполняются, либо нет. Любой вариант, который не проходит хотя бы один жёсткий критерий, выбывает до сравнения функциональности и цены.
Кто на рынке
Чтобы фреймворк не остался теорией — коротко о типах решений. Это не рейтинг: конкретную систему выбирают под цели и критерии выше, поэтому важно понять, к какому классу присматриваться.
Простые таск-трекеры и канбан-доски — карточки, доски, базовая автоматизация. Для тех, кому Jira была нужна просто как доска со спринтами. Дёшево и быстро стартуют, но рано упираются в потолок: слабая связь с Git, мало настроек. Малым командам и стартапам.
Системы для управления разработкой — полноценный Scrum и Kanban, бэклог, релизы, интеграция с Git. Ближайшая замена «той самой Jira» для продуктовых команд с большой историей. Главный вопрос — насколько глубоко переедут данные.
ITSM и ESM-платформы — замена не только Jira, но и Jira Service Management с Confluence: заявки, инциденты, портал поддержки и база знаний в одном месте. Для тех, у кого Atlassian держал и разработку, и поддержку, и всю документацию. Перенос базы знаний из Confluence — отдельная задача: важно, сохранятся ли структура страниц и вложения. А если нужно подключить ещё HR, юристов, финансы — это уже ESM.
Конкретные продукты с ценами и сравнением — в отдельных подборках:
[Российский рынок ITSM-систем]
[Аналоги Jira Software: 10 российских систем]
[Рейтинг российских аналогов Jira SD 2026]
[Рейтинг российских систем управления ИТ-проектами 2025]
Здесь важнее, к какому классу ведут именно ваши цели.
Как не потратить миграцию впустую
Цели и отсекающие критерии отвечают на вопрос «что нам нужно сейчас». Но у выбора системы есть второе измерение, которое легко недооценить на входе: куда это решение позволит вырасти через два-три года.
Набор точечных инструментов закрывает текущие задачи, но плохо масштабируется. Системы, которые проектировались независимо друг от друга, в будущем не интегрируются органично — между ними всегда будет слой костылей: коннекторы, промежуточные базы, ручные выгрузки. Каждое обновление одного инструмента потенциально ломает связку с другим. Чем дольше живёт такая конфигурация, тем дороже её поддерживать и тем сложнее в неё что-то добавить.
Платформенное решение с глубокой кастомизацией работает иначе. Собственные атрибуты, таблицы, поля, настройка процессов под конкретную команду дают возможность адаптировать систему под реальную логику работы, а не подстраивать работу под систему. Новые подразделения подключаются в тот же контур, данные между процессами передаются без посредников, и команда, которая уже знает интерфейс, не переучивается заново. Поэтому выбор платформы с запасом по кастомизации и масштабированию — это и есть тот самый шанс сделать лучше, чем было.
Управление изменениями
Фреймворк выбора системы решает только половину задачи — вторая половина в том, как команда примет новый инструмент. Команда годами знала неудобства Jira наизусть и научилась их обходить. Новый инструмент на старте всегда кажется хуже, потому что привычки ещё не выработаны.
Директивный переход этот эффект усиливает. Когда людям говорят «с понедельника работаем здесь» и показывают готовый процесс, они воспринимают это как навязывание, а не как улучшение. Продуктивнее приглашать команды к настройке: показывать конкретные сценарии, где стало меньше шагов, давать возможность настроить процесс под себя. Люди, которые участвовали в конфигурировании системы, сопротивляются её использованию значительно меньше.
И при этом можно (и даже нужно) реально подстроиться под потребности этих сотрудников, потому что внедрение, при котором система меняется, а процессы остаются теми же — это смена названия, не смена качества работы. Импортозамещение дало формальный повод пересмотреть то, что давно требовало пересмотра. Компании, которые это используют, выйдут из перехода с другим уровнем зрелости. Те, кто воспринимает переход как вынужденную техническую замену, получат новый интерфейс со старыми проблемами.
***
А вы уже проходили этот переход? Расскажите, что выбрали и обо что споткнулись.