Импортозамещение Jira и ServiceNow в 2026: как мигрировать на российский ITSM

Почему пришлось мигрировать

В 2022 году Atlassian отключил российским компаниям доступ к Jira Cloud и Confluence, прекратил продажи и поддержку on-premise. В том же году ServiceNow свернул работу с РФ-юрисдикциями. К 2026 году ситуация не изменилась: ни одна из крупных западных ITSM-платформ не работает легально с российскими юрлицами.

Корпоративные ИТ-команды столкнулись с тремя задачами:

• Юридическая — невозможность продлевать лицензии, отсутствие договорной поддержки, риски при аудите;
• Техническая — устаревшие версии on-premise теряют security-обновления; cloud-инстансы могут быть отключены без предупреждения;
• Регуляторная — требования по локализации ПДн (ст. 18 152-ФЗ), включение в Реестр отечественного ПО для участия в госзакупках.

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

Российские альтернативы Jira/ServiceNow

Рынок российских ITSM-решений делится на три сегмента:

Тяжёлые корпоративные платформы

Naumen Service Desk, SimpleOne, 1С:ITIL — комплексные системы для enterprise. Сильные стороны: глубокая ITIL-методология, готовые интеграции, годами отработанные процессы. Слабые стороны: дорого (от 2 млн ₽ на старте), долгий цикл внедрения (6-12 месяцев), привязка к консалтингу вендора.

Middle-сегмент

OkDesk, EvaTeam, TIQQET — модульные системы для команд 20-300 человек. Балансируют функционал и стоимость: лицензии 5-50 тыс. ₽/мес, внедрение 1-2 недели. Закрывают 80% функционала Jira за разы меньшую стоимость.

Лёгкие тикет-системы

HelpDeskEddy, Manageengine SupportCenter Plus (есть РФ-версия) — для команд до 20 человек. Не покрывают полный ITIL, но дешёвые и быстрые.

Для большинства миграционных проектов с Jira/ServiceNow подходит middle-сегмент: функциональный паритет на 80-90%, понятный TCO, простой переход.

Дорожная карта миграции из 7 шагов

1. Аудит текущего состояния (1 неделя). Сколько активных проектов, типов заявок, кастомных полей, workflow, ролей. Без этого выбор системы будет интуитивным.
2. Шорт-лист 3-5 систем (1 неделя). Запросить демо, прайс, реквизиты для договора. Проверить наличие в Реестре отечественного ПО.
3. Пилот 2-3 системы (2-3 недели). Развернуть в изоляции, перенести 10-20 типовых заявок. Дать 3-5 операторам поработать.
4. Выбор и закупка (1-2 недели). Договор, акт о соответствии, юр.документы.
5. Подготовка инфраструктуры (1 неделя). Сервер, БД, домен, SSL, бэкапы.
6. Миграция данных (1-2 недели — см. следующий раздел).
7. Запуск и обкатка (2-4 недели). Параллельная работа со старой системой, постепенное переключение пользователей.

Миграция данных: тикеты, пользователи, SLA

Самая болезненная часть — перенос исторических тикетов. Подходы:

• Полная миграция через CSV/Excel-импорт. Экспорт всех заявок из Jira в Excel (есть штатный экспорт), маппинг колонок, импорт в новую систему. Самый частый сценарий. Минус: вложения нужно мигрировать отдельно.
• Миграция через REST API. Если в новой системе есть API (например, в TIQQET — Public API v1) — можно написать скрипт-конвертер. Сохраняет вложения, комментарии, статусы.
• Только активные заявки. Закрытые тикеты остаются в Jira (read-only мог-сервер), новые создаются в новой системе. Самый быстрый путь для крупных проектов с 10к+ тикетов.

Пользователи — проще: экспортируешь user list, импортируешь в новую систему. Если есть AD/LDAP — настраиваешь sync в новой системе (поддерживают почти все).

SLA-правила нужно переписать: каждая система описывает их по-своему. Не пытайтесь автоматически конвертировать — потратите больше времени на отладку, чем на ручное создание 5-10 правил.

Подводные камни и типовые ошибки

• Не учли кастомные поля. В Jira типичная команда использует 20-40 кастомных полей в разных проектах. В новой системе их может не быть как класс — нужно проверить заранее.
• Не учли интеграции. Slack-бот, GitHub-webhook, Confluence-линки — всё это отвалится. Каталогизируй интеграции до миграции.
• Не успели обучить команду. Новый UI = 2-4 недели снижения производительности. Закладывай это в план.
• Старые URL-ссылки. В корпоративных вики и почтовых тредах остаются ссылки на старые тикеты JIRA-1234. Нужно либо настроить redirect, либо смириться с битыми ссылками.
• Не настроили резервное копирование сразу. Включить бэкап БД, проверить восстановление — это первое что нужно сделать в новой системе.

Сравнение TCO до и после миграции

Усреднённый расчёт для компании 200 человек, 20 операторов поддержки:

Экономия — в 3-4 раза. Плюс юридическая чистота, рублёвая цена без валютных рисков, локализация ПДн.

Вывод

Импортозамещение Jira/ServiceNow в 2026 — задача не «если», а «когда». Российский ITSM-рынок созрел: middle-сегмент закрывает потребности 80-90% команд при кратно меньшей стоимости. Главное в проекте миграции — методичная подготовка и реалистичный график. Технически — это решаемо за 2-3 месяца. Организационно — обычно дольше, но плановость лучше «срочно бежать когда отключили».