Шесть этапов миграции
Любая миграция Service Desk укладывается в шесть последовательных этапов с параллельной работой старой системы. Общая схема:
Этап 1. Аудит того, что есть
Нельзя перенести то, что не описано. Зафиксируйте:
- Проекты/очереди Service Desk и их назначение.
- Типы запросов и формы каталога услуг.
- Активные SLA: метрики, рабочие календари, правила пауз.
- Кастомные поля и какие из них реально используются (обычно половину можно выбросить).
- Workflow: статусы, переходы, условия.
- Интеграции: почта, AD/LDAP, мониторинг, мессенджеры.
- Объём данных: сколько открытых заявок, сколько исторических.
Этап 2. Экспорт данных из Jira
Jira (Server/DC/Cloud) отдаёт данные через CSV-экспорт и REST API. Что выгружать:
- Пользователи и группы — лучше синхронизировать через AD/LDAP в новой системе, а не импортировать списком.
- Активные заявки — обязательно, с комментариями, вложениями, исполнителями.
- Справочники — каталог услуг, типы, приоритеты.
- Исторические заявки — оцените, нужны ли они в оперативной системе или достаточно read-only архива (CSV/выгрузка в БД). Чаще достаточно архива.
Не пытайтесь перенести «всё как было» — миграция это повод убрать накопленный мусор.
Этап 3. Маппинг статусов и SLA
Самый недооценённый этап. Статусы Jira редко совпадают со статусами новой системы один-в-один — составьте таблицу соответствия и обработайте «осиротевшие» статусы. Особое внимание — SLA: проверьте, что рабочий календарь, паузы (ожидание ответа пользователя) и правила эскалации переносятся корректно, иначе сроки «поедут». О тонкостях — SLA в техподдержке и Service Level Management.
Этап 4–5. Пилот и перенос
Не переключайте всех сразу. Возьмите одну команду или одну услугу и поработайте 2–4 недели в новой системе параллельно со старой. Сверьте метрики (SLA compliance, время решения), соберите обратную связь операторов, докрутите формы и маршруты. После успешного пилота переносите активные заявки и справочники, синхронизируете пользователей через AD.
Этап 6. Переключение и откат
Переключайтесь по группам, а не «рубильником»:
- Старая система переводится в режим «только чтение» (новые заявки туда не попадают).
- Канал приёма (почта, портал) перенаправляется на новую систему.
- Группы операторов переключаются волнами, с поддержкой в первые дни.
План отката: до полного переключения держите старую систему доступной для чтения минимум 1–2 месяца — на случай, если потребуется поднять историю или вернуть канал. Резервная копия данных новой системы — с первого дня (см. важность резервного копирования).
TIQQET разворачивается параллельным контуром за день, синхронизирует пользователей через AD/LDAP и принимает заявки по почте и через портал — что делает переключение по группам безопасным.
Попробуйте TIQQET в деле
On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.
Частые вопросы
Сколько времени занимает миграция с Jira?
Базовый контур (каталог, SLA, роли, интеграции) разворачивается за дни. С пилотом 2–4 недели и поэтапным переключением весь проект обычно укладывается в 1–2 месяца — без простоя, так как старая система работает параллельно.
Нужно ли переносить все исторические заявки?
Чаще нет. Активные заявки и справочники переносят обязательно, исторические достаточно сохранить в read-only архиве (CSV или выгрузка в БД). Это ускоряет миграцию и не тащит накопленный мусор в новую систему.
Что чаще всего ломается при миграции?
SLA: рабочий календарь, паузы на ожидание пользователя и правила эскалации переносятся некорректно, и сроки «едут». Поэтому этап маппинга статусов и SLA — самый важный, его проверяют на пилоте.
Как откатиться, если что-то пойдёт не так?
Старую систему держат в режиме чтения 1–2 месяца после переключения, а резервные копии новой делают с первого дня. Переключение по группам (а не всех разом) ограничивает радиус возможной проблемы.