BMC Remedy держит критичный процесс на многих российских предприятиях уже без вендора: американская BMC ушла с рынка, on-prem-версия не получает патчей безопасности, облачный BMC Helix недоступен, а специалистов по языку ARS с каждым годом остается меньше. Систему никто не отключил — она устаревает тихо, без публичного дедлайна и скандала.

Небольшое уточнение по названиям, чтобы дальше не путаться.

• AR System (ARS) — движок, на котором всё написано: формы, workflow, кастом.

• Remedy ITSM — старое название набора приложений поверх него.

• BMC Helix ITSM — новое название той же линейки: она существует и как облако (в России недоступно), и как on-prem-версия, где под капотом всё та же AR System.

Когда в статье говорится «Remedy», имеется в виду вся эта конструкция — то, что физически крутится у заказчика.

Список альтернатив BMC Remedy на российском рынке уже написан десятками обзоров. Эта статья продолжает серию про импортозамещение ITSM-платформ после материалов про Atlassian и ServiceNow.

Развилка здесь другая: там речь шла о выборе среди готовых замен, здесь — о судьбе многолетнего кода, кастомных экранов и процессов, накопленных поверх монолита за десятилетие эксплуатации.

Сложность миграции с Remedy редко сводится к переносу самой системы. За годы работы на ARS у крупных заказчиков накопились сотни кастомных форм, десятки интеграций со смежными системами, собственная CMDB с историей активов. Объем этого кастома определяет стоимость и сроки переезда сильнее, чем выбор конкретной платформы на замену.

Дальше разберем отсекающие критерии для миграции, развилку между переписыванием процессов с нуля и переносом легаси как есть с примерами реальных миграций, стоимость владения старым Remedy против новой платформы и алгоритм перехода по шагам.

Я — Евгений Котухов, технологический партнер SimpleOne, ITSM/ITAM-эксперт. Расскажу, как эта развилка выглядит на практике.

Дисклеймер: я работаю с SimpleOne — одной из российских ITSM-платформ, на которую мигрируют с Remedy. Кейсы ниже в основном её клиенты, это отмечено в тексте

Годы кастома на ARS решают исход миграции

Remedy AR System ведет историю с 1991 года, и поддержка последних on-premise версий уже закрыта: для Remedy AR System 20.02 (в составе BMC Helix ITSM OnPrem) официальная поддержка закончилась в феврале 2025 года. Система продолжает работать, но каждый баг и каждая уязвимость с этого момента остаются на стороне заказчика без вендорских патчей.

За годы эксплуатации на площадке заказчика накопился слой заказной разработки поверх системы:

• Формы и workflow написаны на языке ARS под конкретные процессы компании;

• Интеграции построены через веб-сервисы и API AR System;

• Структура CMDB содержит классы и атрибуты, которых нет в стандартной поставке.

У BMC есть отдельный инструмент Remedy Migrator для переноса данных между серверами, но документация оговаривает: он не переносит мета-workflow и не заменяет установку ITSM/SLA/CMDB-приложений целиком.

CMDB — отдельная головная боль. Стандартной выгрузкой класс и его кастомные атрибуты не перенести: BMC описывает миграцию CMDB как отдельную процедуру с ручным сопоставлением классов между источником и целевой системой. Чем глубже заказчик кастомизировал классы активов и связи между ними за годы работы, тем больше ручной разметки потребует переезд.

Сложность миграции с Remedy определяет объем накопленного заказного кода. Компания с базовым service desk на Remedy мигрирует за недели. Компания с сотней кастомных форм, собственной CMDB и двумя десятками интеграций — за месяцы, и в этом объеме кастома причина, почему готовые чек-листы «выбери альтернативу» здесь не работают.

Отсекающие критерии до вопроса о переезде

Прежде чем разбирать сложность миграции, стоит сузить список кандидатов на замену теми, кто формально может работать у конкретного заказчика. Четыре фильтра снимают часть платформ еще до сравнения фич:

Указ №166 обязывает органы власти и значимые объекты КИИ перейти на отечественное ПО, но сроки за последний год сдвинулись: изначальный дедлайн 1 января 2025 года заменен на три горизонта в зависимости от типа проекта и даты его старта. Для держателей значимых объектов КИИ на Remedy это не повод расслабляться: тренд регулятора — обязательный переход, а платформа на замену должна быть в реестре российского ПО уже сейчас.

152-ФЗ применяется шире, чем КИИ: любая компания, обрабатывающая персональные данные сотрудников или клиентов через ITSM-систему, обязана соблюдать требования по локализации и защите этих данных независимо от отраслевой принадлежности. Remedy на площадке заказчика этому требованию формально соответствует, но при переезде архитектуру хранения данных нужно подтвердить заново.

Переписать заново или перенести как есть

У каждой миграции с легаси-системы есть два маршрута, и выбор между ними определяет бюджет и риски проекта сильнее, чем выбор платформы.

Первый — перенести процессы без изменений: те же поля, статусы, маршруты согласования, тот же внешний вид для пользователя.

Второй — использовать переезд как повод пересмотреть процессы и убрать то, что накопилось за годы работы с монолитом.

Логика решения та же, но техническая сложность отличается: переезд с ARS-легаси с многолетним кастомом сложнее переезда с облачного ServiceNow, где структура данных стандартизована производителем.

• FM Logistic — клиент SimpleOne — выбрал перенос без изменений под жестким сроком: интегратор перенес более 50 000 инцидентов, 4500+ запросов на изменения и свыше 1000 конфигурационных единиц за четыре месяца, сохранив таблицы SLA и процессы incident- и change-менеджмента без изменений.

• Похожим путем прошла розничная сеть «Монетка», тоже клиент SimpleOne: миграция заняла три месяца, интерфейсы адаптировали под привычный пользовательский опыт, и переход остался незаметным для 7500 сотрудников.

• ITGLOBAL.COM пошел дальше простого переноса. После первой миграции ITSM-процессов компания расширила платформу до ESM-уровня на 15+ сервисных подразделений, довела нагрузку до 155 000 обращений в год и добавила модули CRM и ИИ-инструменты.

Сколько стоит держаться за Remedy

Стоимость владения Remedy складывается из трех статей расходов:

1. Лицензии. Прямые лицензии на линейку (Remedy / BMC Helix — в зависимости от того, когда покупали) у российских заказчиков давно оплачиваются через параллельный импорт или продление старых контрактов до ухода вендора — с валютным риском и без официальной поддержки на новые версии.

2. Специалисты. Специалисты по языку ARS стоят дороже рядового ITSM-разработчика именно потому, что рынок этой экспертизы сжимается.

3. Риск простоя. On-prem-инсталляция без вендорских патчей безопасности накапливает уязвимость с каждым годом без обновлений. Для банков и держателей КИИ это не абстракция: регулятор требует соответствия 152-ФЗ и Указу №166 независимо от того, работает ли система физически.

Российские ITSM-платформы функционально догнали Jira SM и ServiceNow, но часто проигрывают в UX/UI, а часть заявленных «экосистем» на практике держится на интеграторах и кастомных доработках, а не на встроенном функционале коробки. Эту оговорку стоит учитывать при расчете TCO новой платформы: если экономия на лицензии Remedy уходит на оплату интегратора, дописывающего интерфейс, реальная выгода переезда меньше, чем показывает прайс-лист.

Стоимость владения Remedy растет линейно — с курсом валюты, дефицитом ARS-разработчиков и накопленным ИБ-долгом. Стоимость владения новой платформой снижается по мере того, как заказчик доводит кастомизацию до нужного уровня и перестает зависеть от интегратора на каждой мелкой правке.

Алгоритм миграции по шагам

Решение о переезде с Remedy строится на последовательности вопросов, а не на одном сравнении фич.

1. Проверить регуляторный статус. Держателям значимых объектов КИИ и госструктурам платформа на замену должна быть в реестре российского ПО уже на этапе выбора.

2. Оценить срок. Если критичный процесс не может простаивать и дедлайн уже назначен, выбор падает на перенос без изменений — как это сделали FM Logistic и «Монетка».

3. Если срок не жесткий — провести аудит кастома. Посчитать количество нестандартных форм, объем workflow на ARS, число интеграций и структуру CMDB.

4. При большом объеме кастома — мигрировать поэтапно, по модулям, начиная с самого критичного процесса, и приглашать команды к обсуждению нового процесса.

5. При небольшом объеме кастома или желании снять технический долг — переписать процессы на новой платформе.

6. Зафиксировать стабилизацию: период параллельной работы старой и новой системы, сверка данных, обучение пользователей на конкретных сценариях «было — стало».

Маршрут выбирает комбинация регуляторного статуса, срока и объема накопленного кастома — тот же принцип работал в статьях про Atlassian и ServiceNow, здесь он применяется к более тяжелому легаси.

Что происходит, если ничего не менять

Remedy на площадке продолжает работать без вендора, без патчей безопасности и без гарантии, что через год найдется специалист, способный разобраться в написанном десять лет назад ARS-коде. Каждый месяц без обновлений прибавляет к накопленному ИБ-долгу: уязвимости в неподтвержденной версии системы никто не закроет.

Для держателей КИИ и банков решение отложить переезд не снимает регуляторное давление — Указ №166 сдвинул сроки до 2028–2036 годов, но не отменил требование перехода на отечественное ПО. Компания, которая тянет с миграцией до последнего горизонта, рискует оказаться в очереди из десятков заказчиков, которым интеграторы физически не успеют помочь одновременно.

Рынок специалистов по Remedy и ARS сжимается быстрее, чем растет список задач на этой системе. Дальше выбор стоит между управляемым переездом на своих условиях и вынужденным переездом в режиме аварии, когда времени на аудит кастома уже не остается.

Резюме

Remedy не отключат по расписанию — решение о переезде каждая компания принимает сама, и чем позже, тем меньше времени остается на аудит кастома и выбор маршрута.

***

А как у вас: держитесь за Remedy до последнего или уже считаете стоимость переезда? Поделитесь опытом миграции в комментариях — особенно интересно, сколько кастома пришлось разбирать и что оказалось самым неожиданным сложным местом.