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 включена в реестр — запись № 14 306 от 26.07.2022. Для госзаказчиков это обязательное условие допуска к закупке.
Как выглядит миграция
Коротко, без магии:
Аудит. Смотрим ваши процессы, версии, кастомизации, интеграции. На выходе — карта совместимости и оценка объема работ.
Перенос. BPMN‑схемы импортируются как есть: модели Camunda 7 переносятся в Digital Q.BPM “один в один”, редактор процессов тот же, поэтому команда осваивается сразу. Kafka‑делегатам достаточно указать имена ваших топиков. Делегаты с другой логикой оборачиваются во External Tasks (движок поставляется готовым микросервисом, кастомные делегаты в него не подключаются. Это осознанное решение ради единой обновляемой поставки); максимум доработки — около 50 строк унифицированного кода для работы с Keycloak, заготовку даем, оформляется библиотекой.
Интерфейсы. Экраны пользователей пересобираются на Digital Q.Palette. Обычно это самая заметная для бизнеса часть, потому что заодно закрываются накопленные UX‑хотелки.
Параллельный прогон и переключение.
Кейс: миграция типового портфеля банка.
Ситуация. Средний банк: 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 в проде — расскажите в комментариях, какой путь выбрали (или пока откладываете?). А если хотите рассчитать объем миграции в цифрах, приходите на бесплатный аудит совместимости.