Что делать с Camunda 7 после прекращения поддержки: руководство по плавному переходу

Здравствуйте! Меня зовут Юрий Юшкевич, я руководитель ИТ-разработки и в последние годы отвечаю за команду, которая развивает и поддерживает нашу внутреннюю платформу оркестрации бизнес процессов на базе Camunda 7. Как и многие, кто использует Camunda 7 в качестве движка для автоматизации процессов, в начале 2025 года я столкнулся с интересной дилеммой: Camunda 7 прекращает развитие, а Camunda 8 вызывает много вопросов.

Почему не Camunda 8?

Шаг 1. Аудит текущего состояния: что нужно зафиксировать AS IS

Шаг 2. Оценка альтернатив: матрица сравнения

Ш аг 3. Гибридная стратегия: пошаговый план

Визуализация процесса перехода

Управление командой: как снизить сопротивление

Выводы: 5 ключевых принципов

кардинально иная архитектура (Zeebe + Kubernetes vs Java‑монолит);Camunda 8 - это распределенный кластер (Zeebe брокеры, gateway, Operate, Tasklist и др.), ориентированный на Kubernetes и горизонтальное масштабирование, тогда как Camunda 7 - встраиваемый Java‑движок с общей БД;
другой подход к моделированию процессов (подмножество BPMN);В Camunda 8 используется менее полный профиль BPMN и смена парадигмы на event‑driven и асинхронные сценарии, что усложняет прямой перенос схем;
существенные затраты на переобучение команды и перестройку инфраструктуры: Kubernetes, Helm, gRPC‑клиенты, observability‑стек - все это нужно не только внедрить, но и поддерживать в проде;
коммерческая модель лицензирования вместо бесплатного CE: полноценная Camunda 8 - это подписка, и TCO ощутимо меняется по сравнению с Community‑редакцией Camunda 7;
так как решение иностранное, то коммерческую версию невозможно использовать в РФ из-за санкций.

Как только Camunda объявила о своих планах насчёт 7 версии к нам начали активнее приходить различные вендоры с предложениями бесшовного перехода на их аналоги. Архитекторы со своей стороны поставили задачу на проработку замены или поиска альтернативных вариантов.После просмотра ряда демо мы выбрали свой путь, который я описал ниже.

Перед принятием решения мы провели инвентаризацию:

Процессы:
общее количество;доля активных (запускаются >1 раза в неделю);
количество «спящих» (запускаются <1 раза в месяц).
Сложность:
среднее число узлов BPMN на процесс;
процент процессов с кросс‑сервисными транзакциями.
Инфраструктурные зависимости:
версии СУБД и middleware;интеграция с внутренними системами(AD, логи, мониторинг и т.д.);
наличие кастомных плагинов и расширений Camunda.
Команда:
уровень экспертизы;
готовность к изучению новых технологий.

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

когда у нас сложные процессы, которые проходят через несколько информационных систем;
когда это много простых процессов внутри одной информационной системы.

На втором этапе наша задача стояла не «выбрать идеальный движок», а сузить поле до 1-2 кандидатов под реальные ограничения инфраструктуры, команды и бюджета и конечно под нашу развилку использования. Мы прошерстили все возможные экспертные источники, почитали отзывы и кейсы внедрений и собрали свой short - лист:

Подход рабочий:

фиксируем критерии (миграция, инфраструктура, лицензии, сроки, BPMN, интеграции);
оцениваем каждую платформу по шкале 1-5, где 5 - максимальный риск или затраты для нас;
обсуждаем матрицу с архитекторами и командой разработки, чтобы убрать индивидуальные искажения.

Вывод:

Для сложных BPMN‑процессов с сильной завязкой на нотацию и экосистему естественный кандидат - Flowable;
Для event‑driven сценариев, микросервисов и долгоживущих процессов больше подходят Temporal или Zeebe OS, которые изначально проектировались под распределенные транзакции и надежное хранение состояния;
Camunda 8 оправдана в компаниях, которые готовы мириться с ограничениями в части поддержки нотации BPMN и которые смогут обойти санкционные ограничения.

!!! Важно не копировать эту таблицу «как есть», а адаптировать шкалы под свою действительность: для кого‑то лицензия - главный стоп‑фактор, а для кого‑то наоборот, критичны compliance‑истории и официальная поддержка вендора.

Проведя сравнительный анализ альтернатив мы выбрали несколько кандидатов на замену, но перед тем как бросаться “во все тяжкие” надо провести PoC(Proof of Concept), то есть проверить будущих кандидатов на замену:

Выберите альтернативный движок (например, Flowable для BPMN heavy‑кейсов или Temporal для event‑driven).
Разверните тестовый кластер (отдельный namespace в Kubernetes или VM).
Настройте CI/CD для нового движка: отдельный pipeline, отдельные окружения, чтобы не мешать текущему продакшену.
Создайте «адаптер» для обмена данными между Camunda 7 и новым движком (через REST, gRPC, Kafka, RabbitMQ - исходя из вашего стека интеграций).

Результат: готовая среда для пилотных процессов без риска уронить текущую систему.

Выберите 2-3 процесса из каждой категории.
Перепишите их на новом движке, сохранив внешние контрактные интерфейсы (REST API, события, схемы сообщений).
Запустите в тестовом контуре и отработайте полный цикл: разработка, деплой, мониторинг, поддержка.
Соберите метрики: время разработки, ошибки, нагрузка на инфраструктуру, отзыв команды
Там где нужна скорость, проведите нагрузочное тестирования.

Результат: данные для оценки масштабируемости решения и реальной стоимости перехода.

Определите приоритетные процессы для переноса (начинайте с наименее критичных, но часто меняющихся).
Для каждого процесса:проанализируйте зависимости;перепишите логику на новом движке;проведите интеграционное тестирование;запустите в продакшене параллельно или с контролируемым переключением.
Настройте мониторинг (логи, алерты, дашборды) параллельно или с контролируемым переключением.

Результат: плавный переход без остановки бизнес‑процессов и без «большого взрыва».

Автоматизируйте развертывание новых процессов (pipeline + шаблоны репозиториев).
Настройте единую точку мониторинга (например, через Open Telemetry) и единый observability‑стек).
Задокументируйте лучшие практики миграции, анти‑паттерны и типовые ошибки..
Проведите ревью архитектуры через 3 месяца после старта активной миграции.

Результат: стабильная гибридная система, в которой Camunda 7 постепенно превращается из «центрального ядра» в «легаси‑остров», контролируемый по рискам и срокам.

Проведите воркшоп:
объясните причины перехода (EoL, лицензии, риск зависания на устаревшей платформе);
ответьте на вопросы о нагрузке и обучении.
Создайте «песочницу»:
выделенный кластер для экспериментов;
доступ к документации и примерам;внутренние демо‑проекты.
Внедрите метрики прогресса:
количество мигрированных процессов;время на один процесс;
число багов на 100 строк кода.
Поощряйте инициативу:
выделите время на хакатоны по оптимизации;
поощряйте авторов лучших решений.

Не торопитесь. Хотя у Comunda 7 CE поддержка закончилась в 2025 году. Уже начали появляться fork-и. Вот один из самых популярных. Это дает окно для плавной миграции, а не “ночного переезда”.
Начинайте с аудита. Без инвентаризации процессов, сложностей реализации и интеграций обсуждение альтернатив превращается в пустую трату времени на холивар.
Тестируйте альтернативы на пилотах. 2-3 процесса за 2 недели покажут реальные сложности.
Вовлекайте команду. Разработчики - ваши главные эксперты.
Имейте план Б. Rollback‑сценарии, расширенная поддержка, форки (например, CIB seven как продолжение Camunda 7) - все это снижает тревожность бизнеса.

В своем телеграм канале опубликовал Чек‑лист для принятия решения о переходе с Camunda 7.

Будет интересно услышать опыт коллег: что вы выбрали в качестве замены Camunda 7 и какие подводные камни обнаружились уже в проде?

Ключевые теги: #оркестрация #bpmn #автоматизациябизнеса #автоматизация_бизнеспроцессов #comunda

Подписывайтесь на Telegram