This document guides you through the update from CadenzaFlow 1.1.0 to 1.2.0 and covers the following use cases:

1. For administrators and developers: Database updates
2. For administrators and developers: Full distribution update
3. For developers: Brand rename: Java packages and Maven coordinates
4. For administrators and developers: Dependency upgrades
5. For administrators: Trivy Security Scan Pipeline

This guide covers mandatory migration steps and optional considerations for the initial configuration of new functionality included in CadenzaFlow 1.2.0.

Database updates

Every CadenzaFlow installation requires a database schema update. Check our database schema update guide for further instructions.

The 1.1 to 1.2 upgrade scripts only record the new version in ACT_GE_SCHEMA_LOG; no tables, columns, or constraints change.

Full distribution

This section is applicable if you installed the Full Distribution with a shared process engine.

The following steps are required:

1. Update the CadenzaFlow libraries and applications inside the application server.
2. Migrate custom process applications. Most projects need only the Brand rename changes described below; library upgrades are transparent.

Before starting, ensure you have downloaded the CadenzaFlow 1.2.0 distribution for the application server you use. This contains the SQL scripts and libraries required for the update. This guide assumes you have unpacked the distribution to a path named $DISTRIBUTION_PATH.

Brand rename: Java packages and Maven coordinates

Rename rule

Across every published artifact and every shipped package, the prefix changes consistently:

• Java packages: org.camunda.* → org.cadenzaflow.*
• Maven groupId: org.camunda.bpm.* → org.cadenzaflow.bpm.*
• Maven artifactId: camunda-* → cadenzaflow-*

No public class names, method signatures, or REST endpoints have changed. Only the namespace path is different.

Migration steps

1. Update Java imports: in your IDE, perform a project-wide find-and-replace of org.camunda. with org.cadenzaflow..
2. Update dependency coordinates in pom.xml, build.gradle, or any BOM you import.
3. Rebuild and redeploy. BPMN, DMN, and CMMN models do not need to change.

Example

Before (CadenzaFlow 1.1.0):

<dependency>
  <groupId>org.camunda.bpm.springboot</groupId>
  <artifactId>camunda-bpm-spring-boot-starter-rest</artifactId>
  <version>1.1.0</version>
</dependency>

import org.camunda.bpm.engine.RuntimeService;
import org.camunda.bpm.engine.delegate.JavaDelegate;

After (CadenzaFlow 1.2.0):

<dependency>
  <groupId>org.cadenzaflow.bpm.springboot</groupId>
  <artifactId>cadenzaflow-bpm-spring-boot-starter-rest</artifactId>
  <version>1.2.0</version>
</dependency>

import org.cadenzaflow.bpm.engine.RuntimeService;
import org.cadenzaflow.bpm.engine.delegate.JavaDelegate;

The same coordinate update applies to Gradle build files and BOM imports — replace org.camunda.bpm with org.cadenzaflow.bpm and camunda-* with cadenzaflow-* consistently.

Dependency upgrades

CadenzaFlow 1.2.0 ships with patched runtime and frontend dependencies, primarily addressing CVE advisories raised in early 2026. No API changes are introduced.

For standard usage no action is required — the 1.2.0 distribution brings every upgraded library in transitively. If your project pins these libraries independently of CadenzaFlow, align your declared versions with the table above to avoid resolution conflicts.

Trivy Security Scan Pipeline

CadenzaFlow 1.2.0 introduces a Trivy-based security scan running on every push and pull request in the upstream repository. The scan publishes results to GitHub’s Security tab and surfaces both library and container-image vulnerabilities.

This change affects the upstream CadenzaFlow repository only; it does not add a new requirement for consumer projects.