Migrate from Camunda 7 to Operaton instead of Camunda 8: the short answer
If you run Camunda 7 Community and need a path off an engine that no longer gets releases or security patches, Operaton keeps the embedded engine, the REST API and the database schema, so the move is much smaller than a re-platform onto Camunda 8. The effort is not fixed, though. It depends on how much of your application is coupled to Camunda 7 Java APIs, delegates, listeners and custom plugins, and on how much database work your schema and history tables need. Camunda 7 Community was archived on November 4, 2025, after its final feature release, 7.24, so the decision needs a date attached to it. Before you commit, inventory custom code and database dependencies, then confirm with the Operaton project which 7.24 behaviors its 2.1 release keeps.
In practice, the work is usually done by an internal platform or application team with an outside partner for the parts that need engine knowledge: the OpenRewrite recipe for imports and artifacts, the database and Liquibase changes, and the review of stored scripts and expressions. Confirm who owns each step in writing, and ask the partner to state its assumptions about running instances, since in-flight processes need a plan separate from the code change. Two routes avoid a Camunda 8 re-platform: staying on Camunda 7 Enterprise, which Camunda has extended to April 9, 2030, with fee-based extended support through April 2032, or moving to Operaton. Compare them on the same inventory, because the Enterprise route keeps your code in place under a commercial contract, while Operaton moves that support obligation to you or to a third-party provider.
Which Camunda 7 capabilities move to Operaton cleanly
This table maps the main Camunda 7 building blocks against Operaton and marks each as clean, needs rework or gap. Read the status column first, then check the notes on the rows that carry real migration effort. The main takeaway is that the engine-level surface is designed to carry over, while Enterprise-only features, CMMN and task list tooling need confirmation before you plan around them.
| Capability | Operaton status | Notes for a Camunda 7 CE team |
|---|---|---|
| BPMN deployment and models | Clean | Operaton states deployable BPMN models are compatible with Camunda 7 CE 7.24. Confirm any vendor-specific extension elements in your models against the release notes. |
| DMN decisions | Clean | Operaton lists DMN 1.3 compliance and deployable DMN models. Test decision tables that use custom expression languages or external functions in a staging environment. |
| REST API | Clean | Operaton states a fully compatible REST API with Camunda 7 CE 7.24. Clients calling the endpoints should work unchanged, but verify any custom REST plugins you have written. |
| Database schema | Clean | Operaton keeps database schema version 7.24, so an existing Camunda 7 CE database is the starting point. Back up the database and rehearse the schema check before cutover. |
| Java delegates and listeners | Needs rework | Code is moved to org.operaton packages, so imports and class references to org.camunda must change. Use the OpenRewrite recipe for imports, then fix stored scripts and expression strings by hand. |
| Spring and Quarkus integration | Needs rework | Operaton ships Spring Boot 4 and Quarkus extension builds. Dependency coordinates, starter names and version pins must be updated, and Spring Boot 4 upgrades can touch other code. |
| Camunda 7 Enterprise features | Confirm | Features tied to Camunda 7 Enterprise Edition are not covered by the community compatibility statement. Confirm each one against the Operaton release notes before planning. |
| CMMN and task list tooling | Confirm | Operaton lists CMMN 1.1 compliance, but the task list and cockpit experience must be checked against your users' needs. Confirm the current tooling with the Operaton project. |
| Camunda 8 path (for comparison) | Needs rework | Moving to Camunda 8 means remodeling execution around Zeebe workers and a remote engine, so Java delegates do not carry over directly. Expect more effort than a fork migration. |
What data and integrations move, and what to rebuild
A Camunda 7 to Operaton move keeps much of the engine model intact, because Operaton shares the Camunda 7 schema and REST API. The work concentrates in four places: the database, the deployed models, the client integrations and the custom code. Each card below covers one of these, with the checks to run in your own environment before you set a cutover plan.
Process database and schema
Running process instances, variables, jobs and history live in the Camunda 7 relational database. Operaton keeps database schema version 7.24, so the existing schema is the starting point rather than a new data model. Confirm with your DBA that your database engine and version meet Operaton's minimums, which are PostgreSQL 14, MariaDB 10.11 and MySQL 8.4 for the 2.1 release, and that Oracle, SQL Server and DB2 are on supported versions. Test the upgrade on a restored copy of production first.
History tables and retention
History tables hold completed instance data used for audit and reporting, and they often grow faster than the runtime tables. Decide which history level you need and whether older history stays in the same database or moves to an archive. Keep in mind that Operaton's schema compatibility covers the tables themselves, so reporting queries and external dashboards built on those tables should continue to work, but confirm this against your own queries.
BPMN and DMN model files
Deployed BPMN and DMN files are the artifacts most teams can move without change, since Operaton states that it deploys the same models. Inventory every model, including those stored in version control, in a database deployment table or in a deployment archive. Check for Camunda-specific extension attributes and expressions that a model validator flags after deployment, and run each model through a test deployment before cutover.
REST API clients and external tasks
Applications that call the REST API or poll external task workers depend on endpoints and payloads that Operaton documents as compatible with Camunda 7 CE. Confirm the endpoint list your clients use, including any calls to the Camunda 7 Enterprise-only features that Operaton does not provide. Verify worker libraries, their topic names, lock durations and retry handling under load, since these settings change behavior when the engine version changes.
Custom code and org.camunda packages
Java delegates, listeners, plugins and scripts that import org.camunda classes must move to the org.operaton namespace, which Operaton changed as part of its fork. The migrate-from-camunda OpenRewrite recipe automates much of the import and artifact work, but it does not catch every reference. Search the codebase and build files for org.camunda strings, then compile and run the full test suite against the Operaton artifacts.
Stored scripts and variables
Script tasks, expression language and serialized variables stored in the database may still reference org.camunda classes or Camunda-specific types after the code changes. Serialized Java objects in process variables fail to deserialize when class names change, so list the variable types in use before cutover. Ask Operaton's community or a service provider to confirm how your specific script engine and variable serializers behave on the new namespace.
Migration sequence from inventory to decommission
This sequence moves a Camunda 7 Community workload to Operaton in controlled stages, so each step produces evidence that the next one depends on. It ends with a Camunda 7 environment that is archived rather than left running unpatched.
Inventory models, code, database and integrations
The engineering lead and the application owners list every deployed BPMN and DMN model, every Java delegate, listener, script task and custom plugin, every REST client calling the engine, and every database schema and external system the processes touch. Record the Camunda 7 version in use and any stored scripts or variables that reference org.camunda classes. The step is done when a single inventory register exists, each item has an owner and a migration decision, and the application owners have signed it off.
Run a pilot on a non-production copy
The development team restores a copy of the production database to a non-production environment, then applies the migrate-from-camunda-recipe OpenRewrite recipe to the application source to convert org.camunda imports and artifacts to org.operaton. They also check the Liquibase changelog path and any configuration that still points at Camunda names. The step closes when the converted application builds, deploys against the copied schema, and passes an agreed automated test suite that covers the critical process paths and custom code.
Fix stored scripts, variables and API consumers
Before any production change, the team reviews what the recipe cannot reach: serialized Java objects in process variables, script tasks written in languages that reference Camunda classes, external clients that call the REST API, and monitoring or cockpit tooling. Each item is fixed or retired and retested in the pilot. Operaton states a compatible REST API and database schema, so REST clients may need only endpoint and namespace checks, but the team should confirm this against its own calls. The step is done when the pilot's defect list is empty for critical paths and the open items have written owners.
Parallel run with new instances on Operaton
The team deploys Operaton in a staging or limited production lane and routes new process starts to it while existing instances keep running on Camunda 7. Operations staff compare outcomes, incidents, job retries and performance against the Camunda 7 baseline, and they verify backup and monitoring for the new engine. The step produces a run report with each discrepancy classified and resolved. It is complete when the agreed evidence set shows the new engine behaves as the baseline does, and the go decision is recorded.
Cut over and drain or migrate in-flight instances
The team writes a cutover runbook covering the freeze on new starts in Camunda 7, the choice for each in-flight instance (let it complete on Camunda 7, or migrate it with a tested procedure), rollback steps, the database backup taken before the change, and the people authorized to decide a rollback. The cutover runs according to the runbook, and the team confirms that no process is stranded in either engine. Done means the runbook is executed with a signed record and the in-flight count on Camunda 7 is zero or accepted by the owners.
Decommission Camunda 7 and archive the environment
Once the drain period agreed in the runbook has passed without incidents, the team stops the Camunda 7 engine, removes its scheduled jobs and access paths, and keeps a read-only copy of the database, models, source tree and deployment configuration under the organization's retention policy. The security team removes credentials and firewall rules that only Camunda 7 used. The step closes with a decommission record listing the archive location, its retention period and the sign-off from the application and security owners.
What drives the effort and how to keep it down
This table lists the factors that most change the effort of moving from Camunda 7 to Operaton, with the reason each matters and how to reduce it. Read each row against your own inventory, since the largest driver is usually custom Java code rather than the platform itself.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Custom Java delegates, listeners and scripts | Each delegate, execution listener and task listener that calls Camunda 7 APIs needs review and testing after the package namespace changes from org.camunda to org.operaton. | Inventory every class that imports Camunda packages, run the OpenRewrite recipe first, and retire delegates no active process still calls. |
| Camunda 7 APIs and plugins in use | Engine plugins, custom job executors, cockpit extensions and identity plugins each need checking against the 7.24 API baseline that Operaton 2.1 targets. | List plugins and API calls before estimating, and remove unused plugins rather than porting them. |
| Database platform and version | Operaton 2.1 sets minimum versions of PostgreSQL 14, MariaDB 10.11 and MySQL 8.4. Older database servers need an upgrade before or during the move, which adds platform work outside the engine. | Confirm your current database version against these minimums early and schedule any database upgrade as a separate, tested change. |
| Number of in-flight process instances | Running instances must finish on Camunda 7 or be migrated, and the number and age of those instances set how long two engines run side by side. | Count active instances by process definition, and plan whether they drain naturally or need a scripted migration with its own test cycles. |
| History retention and history migration | Long history tables and history reports used by dashboards or audit require a decision on what to keep, archive or rebuild. | Set a retention policy with compliance owners, archive older history, and confirm which reports depend on it. |
| Number of environments and release gates | Each environment (development, test, staging, production) needs its own configuration, data copy and regression run. | Reduce environments in scope where possible, automate deployment, and reuse the same test suite across each stage. |
| Internal engineers | Staff time for code changes, testing, operations and database work is usually the largest recurring share of effort and is paid through salaries or contractor time. | Ask for a per-phase effort estimate from the written scope and track it against actual hours. |
| Partner fees under a written scope | A fixed-scope partner engagement charges for defined deliverables, so unclear requirements tend to move cost into change requests. | Ask for a fixed scope listing applications, plugins, environments, database versions and what counts as done. |
| Infrastructure and testing | Production, staging and test hosting, plus load and regression testing, recur for as long as the platform runs. | Right-size the test environments, reuse infrastructure as code, and confirm which costs are one-time versus monthly. |
| Ongoing patch management | Operaton ships half-yearly feature releases with monthly patches and supports each version for 6 months, so upgrades recur on that cadence and need someone accountable. | Assign an owner, schedule upgrades against the April and October releases, and ask any partner for the patch and upgrade terms in writing. |
What usually goes wrong in a Camunda 7 to Operaton move
Most Camunda 7 to Operaton moves are close to a drop-in change, so the failures tend to come from details that were never inventoried. The cards below cover the places where teams lose time: leftover package names, database and runtime floors, running instances during cutover and assumptions about support windows.
Leftover org.camunda references
Operaton renames the package namespace from org.camunda to org.operaton, so Java code is not the only concern. Stored scripts, JUEL or Groovy expressions, serialized variables and custom listeners in the database can still refer to org.camunda classes and fail only when a path executes. Search the process definitions, the database and the deployed resources, not just the source tree, and run the OpenRewrite recipe as a starting point before testing each flow.
Database version gaps
Operaton 2.1 sets minimum database versions of PostgreSQL 14, MariaDB 10.11 and MySQL 8.4, and keeps Oracle 21, SQL Server 2022 and DB2 support unchanged. Many Camunda 7 installations run older database releases that were acceptable under the previous engine. Confirm the current version of every database, including replicas and reporting copies, before scheduling the upgrade, because the database upgrade often becomes the longest item on the plan.
Java 17 runtime requirement
Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25. Application servers, container base images and build agents built for an older JDK must be updated together with the engine, or the deployment will not start. Check the runtime of every application that embeds the engine, including test harnesses and batch jobs, and confirm that third-party connectors and libraries support the same JDK.
Running instances stranded at cutover
Process instances started on Camunda 7 remain in the old schema and must finish or be moved deliberately. Operaton keeps the database schema at version 7.24, so instances can continue, but timers, asynchronous jobs and external task workers that still point at the old application version can hang after a switch. Decide in advance whether instances drain to completion on the old stack, get migrated, or are restarted, and rehearse that path on a copy of production data.
Assuming community support windows match enterprise
Operaton publishes half-yearly feature releases in April and October, with monthly patch releases, and supports each version for 6 months until the next one ships. It has no traditional LTS line, and no single company holds the support contract. Teams used to multi-year enterprise support must plan their own patching cadence, budget for a support provider if they need one, and confirm with independent service providers what response times they can actually contract.
Governance still forming
Operaton is maintained by a community with no single company in control, and the FAQ says governance is still forming and a non-profit organization is planned. For an organization that needs a fixed vendor to answer to, this matters for decisions about roadmap, security disclosure and long-term maintainers. Record who would decide on a critical fix, review the project's contributor activity, and decide whether an internal fork or a paid support contract is needed as a fallback.
How the move differs by starting point
When one Spring Boot application embeds the Camunda 7 engine, the migration is mostly a dependency and code exercise. The engine, its Java delegates, listeners and the process models sit inside one deployable, so the team can run the OpenRewrite recipe against that codebase and test the application end to end. The work centers on the application's own test suite and on confirming that runtime behavior matches before cutover.
- Dependencies: Replace the Camunda 7 starter artifacts with the Operaton equivalents and move imports from
org.camundatoorg.operatonusing the migration recipe. - Configuration: Check properties, the Liquibase or schema setup and any JUEL expressions or scripts that still reference Camunda classes.
- Models: Confirm that BPMN and DMN files deploy unchanged, since Operaton keeps the model support of the Camunda 7 CE baseline.
- In-flight instances: Decide whether running instances finish on the old engine or are moved, and test that path explicitly.
- Runtime: Confirm the database versions and Java version your application targets against the current Operaton requirements.
Before committing, ask the team to run a full regression of long-running process paths, timers and error handling, since these are where embedded engines usually surprise teams.
A shared Camunda 7 platform, where a central engine or a set of applications uses one process engine database, changes the migration from a code task into a coordination task. Each consuming team has its own code, release calendar and test habits, and the database is shared, so a cutover date has to be agreed across owners before any engine version changes. Governance of the shared engine matters as much as the code.
- Inventory: List every application, process definition, custom plugin and external script that depends on the shared engine.
- Sequencing: Agree a migration order that keeps the shared database compatible with every consumer during the transition.
- Schema and rollback: Test the database upgrade path and a rollback plan on a copy of production data.
- Ownership: Name who approves each consumer's cutover and who handles incidents during the window.
- Monitoring: Extend operational dashboards to cover the new engine version before the first application moves.
Ask your platform team to confirm which parts of the shared setup are owned centrally and which belong to product teams, because that split decides who signs off each step.
Organizations on Camunda 7 Enterprise Edition face a different decision. Camunda has extended the Enterprise end of life to April 9, 2030, with fee-based extended support available from April 2030 through April 2032, according to Camunda's announcement. That window changes the urgency and gives time to plan, so the question becomes whether a move to an open-source fork is needed now, later, or not at all.
- Timing: Compare the planned migration effort against the 2030 end of life date and the fee-based extended support period.
- Support contracts: Ask Camunda what remains covered for your version and what the extended support fee covers.
- Dual running: Consider whether a staged move of selected processes is possible while Enterprise remains in place.
- Fork support: Ask Operaton or CIB seven providers for their support options, since Operaton has no commercial editions and relies on independent service providers.
- Contract terms: Check any clause that ties Enterprise features to the platform you plan to leave.
Confirm the exact support dates for your own agreement with Camunda, because account terms can differ from the public announcement.
Teams that have narrowed the choice to community forks of Camunda 7 CE need to compare the two projects on governance, release habits and support rather than on code alone. Both are Apache 2.0 licensed and both start from the Camunda 7 codebase, so most application code moves with limited changes. The differences show up in who maintains the project and how often it ships.
- Governance: Operaton is maintained by a community with no single company in control and is still forming governance, with plans for a non-profit organization. CIB seven is maintained by CIB software.
- Release cadence: Operaton ships half-yearly feature releases in April and October with monthly patches, and each version is supported for six months, with no LTS line.
- Commercial options: Operaton has no commercial editions, while CIB seven offers paid LTS and Enterprise editions, according to its project materials.
- Compatibility: Operaton states API and schema compatibility with Camunda 7 CE 7.24, so check the same baseline for CIB seven.
- Tooling: Compare the task list and cockpit each project provides with the tools your operations team already uses.
Ask each vendor or provider to describe its support commitments in writing, since a six-month support window suits some teams and not others.
How much effort does a Camunda 7 to Operaton migration take?
What drives the effort of a Camunda 7 to Operaton migration?
The main drivers are how much custom code you have, how many integrations depend on Camunda 7 APIs and plugins, and how many database and deployment variants you run. Operaton keeps the REST API, database schema and deployable BPMN and DMN models compatible with Camunda 7 CE 7.24, so a standard embedded deployment with few custom extensions is usually the lightest case. Its repository offers an OpenRewrite recipe for migrating from Camunda 7, which automates much of the mechanical change in imports and artifacts. Stored scripts, expressions and custom listeners that reference org.camunda classes still need manual review, because the package namespace changed to org.operaton. Ask any partner to inventory these items before quoting.
How long does a Camunda 7 to Operaton migration take to plan?
No duration figure is supplied for this work, so treat any timeline as something to confirm against your own inventory. Planning usually starts with matching your current Camunda 7 baseline version, choosing the Operaton release line, and deciding whether to upgrade your Java runtime, since Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25. Your database must also meet the listed minimums, such as PostgreSQL 14, MariaDB 10.11 or MySQL 8.4. Ask for a written plan with phases, test gates and a rollback step before agreeing on dates. Operaton's release cadence of half-yearly feature releases with monthly patches means you should also schedule the first upgrade cycle rather than treat the move as one event.
What does the migration require from our own engineering team?
Your team needs people who know the process models, the Java delegates and listeners, and the database and deployment setup. They must own decisions about which models change, which tests prove behavior is unchanged and how releases are cut. Operaton's compatibility lowers the amount of rewriting, but it does not remove the need for regression testing across every process definition. Expect to provide access to non-production databases, CI pipelines, identity and monitoring systems, and a business owner who can sign off on process outcomes. Confirm these responsibilities in writing so that gaps are visible before work starts.
Can an internal team migrate to Operaton without outside help?
Often yes, if the application is a standard embedded Camunda 7 deployment, the team has Java and database skills, and it can run a full regression suite. The OpenRewrite recipe and the compatible schema make the technical path less risky than a re-platform to Camunda 8. External help becomes more valuable when you have many custom plugins, a large history table to manage, multiple databases, or no time for production-like testing. DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms in your own infrastructure under a fixed scope agreed in writing, so you can choose to cover only the parts your team cannot take on. Use an internal pilot on one process to measure your own effort before deciding.
How does Operaton support differ from Camunda 8 Enterprise?
Operaton has no open-core model and no commercial editions. Its repository states that professional support and consulting come from multiple independent service providers, and its FAQ says governance is still forming, with plans for a non-profit organization to manage key decisions. Camunda 8 Self-Managed in production requires the Enterprise Edition under the Camunda License, which is a paid subscription from a single vendor. The trade-off is contract structure and vendor accountability. Ask any support provider for the response commitments, supported versions and escalation path in writing, and compare them with the Camunda 8 Enterprise terms you would otherwise sign.
When is CIB seven a better fork than Operaton?
CIB seven is the better choice when you want a fork with its own commercial support tiers, its own task list and cockpit, or a vendor-backed LTS line. CIB seven is Apache-2.0 licensed and its core is a native BPMN 2.0 engine inside the JVM, so the migration path is similar in principle. Operaton is the better choice when you want a community-governed project without a commercial edition. Both forks start from Camunda 7 CE, so the code work is comparable. Confirm the support and release terms of each before deciding, because they change over time.
What happens to running process instances during the move?
Running instances are normally kept in the same database and continue under the Operaton engine because the schema is compatible with Camunda 7 CE 7.24. That is the main reason this path differs from a Camunda 8 re-platform, where the Data Migrator must copy instances into a new engine. Before cutover, drain or pause new starts, confirm that open jobs and timers complete, and test a database copy with real in-flight instances. Plan how you will handle history data and any custom history plugins, and confirm the exact procedure for your version with the engine documentation and the migration recipe.
How DeployOpen scopes and runs the migration
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For a Camunda 7 to Operaton move, that means the engagement covers the Operaton runtime, the database it will run on, the deployment path (Docker images, Helm charts or a Spring Boot, Quarkus or Jakarta EE application), and the operational setup around them. The first written deliverable is a scope that names the Camunda 7 version in use, the application servers and database in place, the number of deployed BPMN and DMN models, and every custom Java delegate, listener and script that must be checked for references to org.camunda classes.
Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. For this migration, the decisions to settle first are which fork is the target (Operaton or CIB seven), whether running process instances will finish on Camunda 7 or be moved, and who owns the cutover window. Ask the team to confirm that the repository's OpenRewrite recipe has been run in a test branch and what it did not cover. Ask DeployOpen to specify, in the statement of work, which hardening baseline, backup and restore test, and documentation set are included, and which are optional. Operaton's release cadence means a quote should also say which upgrade path is covered after go-live. A quote follows from that written scope, so the more precise the inventory, the more accurate the quote.
Ongoing support, upgrades and continuous testing are available as a retainer, which matters here because Operaton ships feature releases twice a year with monthly patches and supports each version only until the next one ships. A retainer can cover applying patch releases in a staging environment, testing the process models against new releases, and keeping the backup and restore procedure current. Confirm with your own team which parties hold the Java application code, who approves production changes, and what response expectations you need written into the agreement. DeployOpen prepares the systems and documentation that your auditors may review, but it does not issue audit reports or certifications; independent assessors do that work.
