Camunda 7 все. Что делать тем, кто на ней остался

14 октября 2025 года вышла Camunda 7.24. Это был последний релиз Community Edition. GitHub-репозиторий переведен в архив, issue закрыты, патчей безопасности больше не будет.

Никаких громких заголовков по этому поводу не случилось. А между тем на Camunda 7 в России работают сотни систем: кредитные конвейеры, согласование документов, клиентские заявки, внутренние процессы госкомпаний. Все они теперь работают на движке, который больше никто не поддерживает.

Сразу дисклеймер: у нас в Диасофт есть своя BPM-платформа на форке Camunda 7, поэтому тема миграции нам небезразлична. Но разберем варианты честно, даже те, где наше решение не нужно.

Camunda 7 больше не развивается

Camunda много лет жила по классической open-core модели: бесплатный движок Community Edition + платные Enterprise-фичи и поддержка. В 2025 году компания окончательно сместила фокус на облачную Camunda 8 (это другой продукт с другим движком и другим API, а не «следующая версия») и объявила: Camunda 7 CE закрывается.

Что это значит на практике:

• 7.24.0 – последняя версия на Maven Central. Прямо на странице артефакта(mvnrepository.com/artifact/org.camunda.bpm/camunda-engine/7.24.0) написано: «This library will not receive any new versions or releases».

• Репозиторий архивирован. Если нашли баг, то рассказать о нем некому.

• Патчи безопасности – только по Enterprise-подписке, которая действует до 2030 года. Одна проблема: российским компаниям она недоступна, поскольку Camunda прекратила работу на нашем рынке еще в 2022 году. То есть для российского пользователя разницы между CE и EE больше нет: обе ветки мертвы.

«Работает – не трогай» здесь не сработает

Самый частый аргумент, который мы слышим: «Движок стабильный, процессы крутятся, зачем что-то менять?» Аргумент понятный. Проблема в том, что BPM-движок не живет в вакууме.

Чтобы понять масштаб, посмотрим, из чего он состоит. Camunda 7 – это Java-библиотека, которая живет внутри вашего приложения и собрана из десятков сторонних open-source-компонентов (у одного только camunda-engine на Maven Central есть 45 зависимостей). MyBatis отвечает за работу с базой данных, JUEL вычисляет выражения в схемах, FEEL-движок на Scala исполняет правила DMN, Groovy и JavaScript-движки – скрипты в процессах, Jackson разбирает JSON, а рядом в типовой инсталляции стоят Spring и Tomcat. У каждого из этих проектов свой цикл релизов и свои уязвимости. Пока Camunda 7 развивалась, вендор делал невидимую, но важную работу: с каждым релизом подтягивал свежие версии всех этих компонентов. Теперь эта работа не ведется, а состав 7.24.0 заморожен таким, каким он был в октябре 2025 года.

Если открыть страницу той самой последней версии 7.24.0 на Maven Central, то в блоке Vulnerabilities можно увидеть 28 CVE в зависимостях, включая свежие CVE-2026. Это не дыры в самом движке, а уязвимости в библиотеках, с которыми он собран. Раньше это было рутиной: вышел патч – обновились. Теперь цикл разорван: версии зависимостей зафиксированы навсегда, а список CVE будет только расти. Каждый месяц.

Дальше можем наблюдать эффект домино:

• Безопасники рано или поздно приходят со сканером. Объяснить аудитору, почему уязвимости в центральном компоненте принципиально не будут устранены никогда – задача непростая.

• Окружение продолжает развиваться: выходят новые версии Java, Spring, PostgreSQL. При этом Camunda 7 останется на уровне октября 2025 года, и разрыв будет только увеличиваться.

• Обычные разработчики не хотят поддерживать мертвый стек. Для инженера это карьерный тупик: опыт с платформой, у которой нет будущего, ничего не добавляет резюме. Сильные уходят первыми – туда, где стек живой. А тех, кто через два-три года все еще будет готов разбираться в замороженной Camunda 7, придется искать долго и оплачивать как экзотику – сценарий COBOL, только в миниатюре. 

Отдельный пункт для госкомпаний и владельцев объектов КИИ. Да, Camunda 7 бесплатна, ее не закупают, и нормы о закупках иностранного ПО ее формально не касаются. Но регулятору неважно, платили вы за софт или нет: open source из иностранной юрисдикции – это все равно иностранное ПО. С 1 января 2025 года его запрещено использовать на значимых объектах КИИ (Указ № 166), в реестре отечественного ПО его нет, и в плане импортозамещения Camunda 7 стоит в графе «подлежит замене». Так что для этого сегмента риск двойной: регуляторный и технологический.

Что делать: три пути

Развилка выглядит так.

Путь 1. Поддерживать форк самостоятельно. Код открыт (Apache 2.0), так что формально ничего не мешает забрать форк себе и развивать дальше. Звучит просто, но дальше начинается полноценная продуктовая разработка. Движок – это ~1,4 млн строк кода, свой цикл отслеживания CVE по всем зависимостям, регресс-тесты, совместимость с новыми версиями Java и СУБД. По сути, вы открываете у себя маленькую продуктовую компанию, которая ничего не зарабатывает. Для одного-двух проектов экономика не сходится никак. Осмысленно только для очень крупных инхаус-команд, у которых Camunda – критическое ядро, и уже есть выделенные люди.

Путь 2. Переписать на несовместимую платформу. Перейти на другой BPM-движок или на Camunda 8 (кстати, миграция на эту версию приравнивается к переписыванию, потому что другой движок, другое API, и для российских компаний она так же недоступна). Плюс: можно заодно пересмотреть архитектуру. Минус: это большой проект. Сам вендор пишет про переход с 7 на 8: «Camunda 8 – не drop-in replacement; заменить библиотеку недостаточно – придется адаптировать BPMN-модели, рефакторить код и, вероятно, пересмотреть архитектуру решения». Под это у Camunda выпущен отдельный инструментарий (Migration Analyzer, Diagram Converter), а в опубликованном ими же кейсе (camunda.com/blog/2024/10/inside-a-camunda-7-to-camunda-8-self-managed-migration) миграция одного решения заняла четыре месяца – с поддержкой вендора и обходными решениями. Теперь умножьте на ваш портфель процессов и вычтите поддержку вендора.

Путь 3. Мигрировать на поддерживаемый форк. Тот же движок, та же процессная модель BPMN 2.0, совместимые API, но за ним стоит вендор, который выпускает обновления, закрывает CVE и отвечает по SLA. Схемы и интеграции переносятся, а не переписываются. Компетенции команды сохраняются: люди, которые писали под Camunda 7, продолжают работать в знакомой парадигме. 

С третьим вариантом как раз можем помочь мы: у «Диасофт» есть поддерживаемый форк Camunda 7 Digital Q.BPM. Но здесь важнее сам подход – для компаний с заметным числом процессов это часто самый короткий путь к поддерживаемой платформе без полной переписи процессов и интеграций.

Что касается миграции на форк, стоит отметить важный момент. Стоимость миграции определяется не фактом переезда, а объемом того, что придется переписать. При смене платформы переписывается все: схемы конвертируются, делегаты переделываются под другое API, интеграции и мониторинг собираются заново, историю процессов чаще всего просто бросают, команду переучивают. При переходе на форк движок, API и схема БД те же – схемы, делегаты, REST-клиенты и накопленные данные работают как работали. Остается замена поставки, регресс-тестирование и, если хочется, обновление интерфейсов. Это не ноль (обещать «переедете за выходные» не будем), но это другой порядок величины.

ИТ-индустрия проходила это не раз. Когда Red Hat закрыл CentOS, серверные парки мировых компаний мигрировали на форки AlmaLinux и Rocky Linux штатным скриптом in-place – часы на сервер, а не месяцы проекта. MySQL → MariaDB – официальный drop-in replacement. Elasticsearch → OpenSearch – та же история. А самый показательный пример из мира BPM: сама Camunda в 2013 году родилась как форк Activiti, и компании переходили на нее заменой библиотеки. Совместимый форк – это штатный механизм выживания open-source после ухода вендора.

Что мы сделали с форком

Digital Q.BPM – это движок на базе форка Camunda 7, который мы развиваем как коммерческий продукт. Мы на этом пути не одни. Российских форков Camunda 7 уже несколько, и это подтверждает, что путь рабочий. Но здесь важно: совместимость с API Camunda 7 – это свойство любого форка по определению. Поэтому сравнивать форки нужно по тому, что происходит со всем вокруг движка. Если форк воспроизводит ядро, но оставляет обвязку вам, вы мигрируете движок, а не платформу – и все остальное снова строите руками. 

Дальше речь пойдет о том, что входит в Digital Q.BPM «из коробки» и куда платформа ушла от точки форка.

Движок живой и стал быстрее. Мы выпускаем обновления, отслеживаем и закрываем уязвимости в зависимостях – ровно ту работу, которую для CE больше никто не делает. Также у Digital Q.BPM есть роадмап и техподдержка с SLA. Заодно мы сняли известный тормоз оригинала: Camunda пишет историю исполнения в свою же БД и теряет на этом порядка 30% производительности, в Digital Q.BPM история уходит событийно в отдельный сервис мониторинга.  Для высоконагруженных сценариев есть реализация движка на Go. Цифры из отчета о нагрузочном тестировании (Kubernetes-стенд, миллион запусков процессов, 1000 виртуальных пользователей, суммарно ~800 часов испытаний): Go-движок держит 24 800 TPS на простом процессе и гарантированные 4000 TPS на сложном бизнес-процессе – против 3056 и 950 TPS у Java-версии. В асинхронном обмене через Kafka – 190 сообщений/с против 120. Время отклика по 90-му перцентилю – 0,9 с, потерь сообщений и ошибок – ноль.

Пользовательские задания переработаны полностью. Tasklist Camunda годился для демо, но не для операциониста, который обрабатывает 200 заявок в день. В Digital Q.BPM это отдельный модуль над движком: шаблоны заданий с назначением на пользователя, группу или элемент оргструктуры; распределение с учетом навыков, загруженности и производственного календаря; SLA и эскалации; уведомления по пяти каналам (email, SMS, мессенджеры, push, API внешних систем); представления списком и канбаном, переназначение и история по каждой задаче.

Интерфейс может быть любой. Вместо стандартных Cockpit/Tasklist экраны собираются на low-code платформе Digital Q.Palette (Angular/React) - от простой формы заявки до полноценного рабочего места. Это снимает классическую боль Camunda-проектов, когда фронт-офис необходимо писать с нуля

Эксплуатация процессов как продукт. Здесь есть все, что нужно для управляемой работы с процессами в проде: версионирование с визуальным сравнением двух версий по диаграмме, параметрам и XML, канареечные запуски Champion/Challenger (часть вызовов идет на новую версию процесса, остальные – на предыдущую расписания), KPI процесса, права доступа и миграция уже запущенных экземпляров на новую версию. Для мониторинга – тепловые карты по длительности, частоте и объему данных в БД, а для разбора проблем – отладка с брейкпойнтами и логами конкретного потока.

ИИ встроен в контур платформы. ИИ-агенты строят BPMN-схему по текстовому описанию с итеративной доработкой, верифицируют бизнес-логику процесса и предлагают варианты исправления и оптимизации, генерируют скрипты по текстовому промпту и автоматически готовят регламенты и описания процессов. Можно создавать собственных агентов. По нашим замерам, это ускоряет разработку до 6 раз и снимает до 80% рутины проектирования.

Симулятор процессов. По сути, это цифровой двойник процесса: для каждого шага задаются время выполнения, стоимость, исполнители и график работы. Затем можно за несколько секунд проиграть месяцы реальной работы, увидеть узкие места прямо на схеме и сравнить сценарии «что, если» по стоимости, срокам и SLA. Результаты дополнительно анализирует ИИ-агент и подсказывает, где процесс можно улучшить. В Camunda 7 такого инструмента не было.

Запись в реестре отечественного ПО. Digital Q.BPM включена в реестр – запись № 14306 от 26.07.2022. Для госзаказчиков это обязательное условие допуска к закупке.

Как выглядит миграция

Коротко, без магии:

1.      Аудит. Смотрим ваши процессы, версии, кастомизации, интеграции. На выходе – карта совместимости и оценка объема работ.

2.      Перенос. BPMN-схемы импортируются как есть: модели Camunda 7 переносятся в Digital Q.BPM «один в один», редактор процессов тот же, поэтому команда осваивается сразу. Kafka-делегатам достаточно указать имена ваших топиков. Делегаты с другой логикой оборачиваются во External Tasks (движок поставляется готовым микросервисом, кастомные делегаты в него не подключаются. Это осознанное решение ради единой обновляемой поставки); максимум доработки – около 50 строк унифицированного кода для работы с Keycloak, заготовку даем, оформляется библиотекой.

3.      Интерфейсы. Экраны пользователей пересобираются на Digital Q.Palette. Обычно это самая заметная для бизнеса часть, потому что заодно закрываются накопленные UX-хотелки.

4.      Параллельный прогон и переключение.

Кейс: миграция типового портфеля банка.

Ситуация. Средний банк: 40 процессов на Camunda 7 (кредитный конвейер, сервисные заявки, согласования), ~120 Java-делегатов, две трети из них работают с Kafka. Поддержка движка закончилась, ИБ-аудит на носу.

Решение. BPMN-схемы импортированы в Digital Q.BPM без конвертации, движок общий. В Kafka-делегатах указаны имена топиков – минуты на делегат. Остальные делегаты обернуты в External Tasks поверх готовой библиотеки Keycloak (~50 строк унифицированного кода). Экраны пересобраны на Digital Q.Palette, проведен параллельный прогон.

Результат. Проект такого масштаба измеряется неделями. Для сравнения: миграция одного решения на несовместимую платформу в опубликованном кейсе самого вендора Camunda заняла четыре месяца.

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

Вместо вывода

Camunda 7 была отличным движком – собственно, поэтому мы и строим продукт на ее форке, а не пишем свой с нуля. Но продукт, у которого не будет ни одного нового патча, – это тикающий техдолг с растущим списком CVE.

Вопрос уже не в том, мигрировать ли вообще, а в том, когда и на что. И откладывать решение становится все дороже: совместимость с окружением постепенно расходится, список уязвимостей растет, а специалисты со знанием Camunda 7 со временем только дорожают.

Если у вас Camunda 7 в проде – расскажите в комментариях, какой путь выбрали (или пока откладываете?). А если хотите рассчитать объем миграции в цифрах, приходите на бесплатный аудит совместимости.