What a Camunda 7 to Flowable migration involves
Moving a Camunda 7 or Activiti estate to Flowable means changing the engine that runs your BPMN process applications, and with it the deployed process models, the Java code behind service tasks, and the data the engine holds. Teams usually start for one of three reasons: licensing terms, the direction of the engine's development, or a wider platform change that puts Flowable's Java and REST APIs at the center of their stack. Flowable's engineering blog, dated September 7, 2022, states that Camunda 7 and Activiti data, including active process instances and history, can be migrated to Flowable in place.
The first practical step is an inventory. Flowable's free LEAP tool reports ahead of time what a migration involves, so run it against a copy of your production database before you commit to a plan. Then review each process model for Camunda or Activiti extension attributes, listeners and expression syntax in the BPMN XML, and each Java delegate or task listener that depends on engine classes. Ask Flowable to confirm which Camunda 7 and Activiti versions the tool and the in-place path cover for your estate.
The data decision drives cutover risk. Active instances can be migrated in place, but you still have to decide whether long-running instances finish on the old engine, move in one batch, or move in waves during a freeze window. Count timers, asynchronous jobs and open human tasks, since these are what users and downstream integrations notice when they stall. List any dependence on Camunda's own admin and task UIs as well, because those belong to Camunda and will not come with the Flowable engine, so confirm what replaces them.
In short, a team with Java and BPMN experience can do much of this in-house: the inventory, porting delegates, updating BPMN XML, and running regression tests against a database copy. A partner is common when in-flight volume is large, the cutover window is narrow, or the estate carries substantial Camunda-specific UI and extension code. Ask for the inventory output in writing before you compare options, because it sets the scope for any fixed-scope quote.
What the work includes
The migration breaks into a fixed set of work packages, each with a named deliverable. Scope and deliverables are agreed in writing before work starts, so the boundaries below can be checked against your own estate.
LEAP assessment and report review
Flowable's free LEAP tool reports ahead of time what a migration from Camunda 7 or Activiti involves. We run it against your database and process estate, then review the report line by line with your team. The check here is whether every flagged item maps to a named work item, so nothing surfaces for the first time during cutover.
In-place data migration plan and rehearsal
Flowable documents an in-place migration path for Camunda 7 and Activiti data, including active process instances and history. The plan defines the migration order, the database backup point, the expected schema changes and the verification queries that prove counts and states match. The rehearsal runs this plan end to end at least once before any production attempt.
BPMN XML and extension element changes
Process definitions carry Camunda-specific extension elements, such as service task implementations, listeners and form references, that do not carry over unchanged. We rewrite these to Flowable equivalents and diff each model against its original. Review the diff for every deployed process, not only the ones that appear in the LEAP report.
Porting Java delegates and listeners
Java delegates, execution listeners and task listeners written against Camunda 7 APIs are ported to Flowable's delegate and listener interfaces. Business logic stays in place and only the engine-facing code changes. Check that transaction boundaries, variable access and exception handling behave the same way in the ported code.
In-flight instance strategy
Running instances at cutover need an explicit decision: migrate them in place, let them finish on the old engine, or cancel and restart. The choice depends on process duration, timers and external callbacks. Document the decision per process definition and confirm how many instances each option affects before the cutover date is fixed.
Testing on a database copy
Migrated data and ported process code are tested against a recent copy of the production database, not a seeded test set. The test set covers open instances at each major state, timers, asynchronous jobs and history queries used by reports. Record the results and any defects so that the cutover decision rests on evidence from real data shapes.
Cutover runbook with rollback
The cutover runbook lists each step in order, with an owner, a check and a decision point. The rollback section states the point after which reverting is no longer clean, and it is rehearsed alongside the forward path. Ask for the runbook to be reviewed by the operations team that will execute it.
Handover documentation
Handover covers the ported code, the changed model set, the migration and cutover records, the rollback procedure and the open items list. It is written for the engineers who will maintain Flowable after go-live. Confirm the format and the walkthrough sessions in the written scope so the handover is accepted as a defined deliverable.
What drives cost and duration
This table lists the migration factors that most change effort and schedule for a Camunda 7 to Flowable move, with a practical way to reduce each one.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Process definitions and extension elements | Each BPMN file using Camunda extension elements, such as class, expression, form key, listener and input/output mappings, needs a Flowable equivalent and a test. | Inventory every definition with the LEAP report, group recurring patterns and convert each pattern once. |
| In-flight instances and long-running timers | Running instances and pending timers must carry over correctly, and the more of them exist at cutover, the more reconciliation is needed. | Count active instances and timers during planning, decide per definition whether to migrate or drain, and check timer due dates on a database copy. |
| Size of history data | Flowable's in-place migration includes history, so large history tables lengthen copy, migration and verification runs. | Confirm history retention with the business owners, archive records your policy allows to leave behind, and size the test copy from the real volume. |
| Camunda web apps and custom task UIs | Flowable 7.0.0 removed the UI applications, so Tasklist, Cockpit and Admin functions must be rebuilt or replaced before operators can work. | List the screens operators and administrators use, reuse the REST APIs where possible and scope the UI as a separate work package. |
| Java delegates and listeners | Camunda delegate and listener classes must be ported to Flowable interfaces and Spring beans, and each port needs unit and process tests. | Count the classes, move shared logic into plain services first, and test each delegate against the Flowable API before the process tests. |
| Database engine and version | The engine and its version affect schema scripts, locking, date precision and vendor-specific behavior. MySQL versions below 5.6.4 lack millisecond precision. | Confirm the target database and version early and run the migration rehearsal on the same engine and version used in production. |
| Number of environments | Each environment repeats the migration, configuration, testing and sign-off, so environment count multiplies effort. | Rehearse once on a database copy, script the migration steps and reuse the same scripts in every environment. |
| Integrations and event consumers | Systems that start processes, correlate messages, run external task workers or consume engine events must be repointed and retested. | Inventory every caller of the Camunda REST API, message endpoints and event consumers, and decide where a compatibility layer is needed. |
| Compliance evidence for change approval | Change boards may require the migration plan, reconciliation of instance counts, test records and a rollback record. DeployOpen prepares this evidence, but auditors and approvers decide whether it is sufficient. | Agree the evidence list with change approvers before testing starts and collect it as each step runs, not after cutover. |
Migration phases and outputs
The migration runs in six ordered phases, each closing with a written artifact that gates the next phase so that cutover is decided on evidence rather than assumption.
Run discovery and the LEAP report
We inventory the Camunda 7 or Activiti deployment, including process definitions, delegates, listeners, custom forms, identity usage, database size and in-flight instances. Flowable's free LEAP tool is run against a copy of the data to report what a migration involves. The LEAP report review closes this step, and the output is a discovery inventory signed off by your team.
Build the gap analysis and target design
Each finding from discovery is recorded in a gap register with an owner, a disposition and a test approach. Decisions cover BPMN and XML extension changes, which Java delegates are ported or rewritten, how identity is handled through the Flowable identity service, and whether tasks use your own task UI because Flowable's open source UI applications are no longer provided. The signed gap register and target design document close this step.
Port the models, delegates and build
Process models and XML extensions are converted, delegates and listeners are adjusted to Flowable APIs, and the application is built and deployed to a non-production environment. Each ported process is checked against its gap register entry. The closing output is a green build with a port log that maps each source element to its Flowable equivalent.
Rehearse the migration on a database copy
The in-place migration is run against a copy of the production database, starting from a snapshot that includes active instances and history. Each run is timed, failures are classified, and fixes are retested until the run completes cleanly. The rehearsal log, with run results, defects and the agreed fixes, is the evidence that the procedure is repeatable.
Run the parallel period or cutover window
Where in-flight work must continue, new starts are directed to Flowable while legacy instances are monitored, or a single cutover window is executed from the cutover runbook. The runbook lists the freeze point, migration commands, verification queries, rollback triggers and the people who decide. Completion is confirmed when reconciliation checks match the rehearsal results.
Provide hypercare and handover
After go-live, the team watches job execution, async jobs, error queues and business metrics for an agreed period, then fixes defects found in production. Operational runbooks, monitoring setup and known-issue lists are transferred to your operations team. The signed handover pack and closed hypercare log mark the end of the engagement.
What teams keep in-house and what they outsource
This table shows who usually owns each part of a Camunda 7 to Flowable migration, the skills each part needs, and the point at which a partner becomes worth considering.
| Work area | Usually owned by | Skills required | Decision point for a partner |
|---|---|---|---|
| Process owners and business rules | Process owners and business analysts, with Camunda 7 operating experience helping them keep ownership | Knowledge of current process behavior, exception paths and DMN decision tables | Partner only if the rules are undocumented and must be reverse engineered from the Camunda 7 models |
| Java developers porting delegates | Internal developers who know the existing Camunda 7 codebase, supported by a partner where the port is large | Java, Spring, the Camunda 7 delegate API and the Flowable equivalents | Consider a partner when many delegates depend on Camunda-specific APIs or internal libraries |
| BPMN XML extension changes | Internal developers with a partner reviewing the converted models | Working knowledge of BPMN extension elements and the Flowable namespace and listener syntax | Consider a partner if the model count is high and no one on the team has converted BPMN XML before |
| Database and operations staff running the migration | Internal DBAs and platform operators, who hold the production database and backup access | Database administration on the target platform, backup and restore, migration tool execution and rollback planning | Partner if the team has no experience running in-place data migrations against live engine tables |
| Test automation | Internal QA with developers, often extended by a partner for regression suites | Test design for long-running process models, automated engine testing and database-copy test runs | Partner when regression coverage of existing processes is thin and must be built before cutover |
| Cutover coordination | Internal release management and the process owners who accept go-live | Change management, scheduling, drain of in-flight work and communication with dependent systems | Partner to plan and rehearse the cutover sequence if the migration touches many integrated systems |
| Post-go-live support | Internal operations and development teams once the platform is handed over | Monitoring, incident handling on the Flowable engine and routine upgrade work | Partner when a retainer covers response, upgrades and continuous testing after cutover |
| Acceptance testing | Process owners, since they decide whether migrated instances behave correctly | Business judgment on expected outcomes and sign-off against the original process behavior | Keep in-house; a partner can prepare test cases and evidence but the business owner signs off |
What usually goes wrong
Most Camunda 7 to Flowable problems come from work that was already running, from behavior the source system provided implicitly, and from plans that were never tested end to end. Each pattern below has a specific check that can run before cutover.
In-flight work and timers
Running instances, pending timers and queued async jobs can behave differently after cutover if their state is not compared with the Camunda 7 source. Count active instances, timer jobs and async jobs before and after migration on a database copy. Then confirm that due timers fire and async jobs run on Flowable's async executor before any production traffic moves.
Extensions and expressions not carried over
Camunda-specific BPMN XML attributes, such as delegate class and expression bindings, listeners and input or output mappings, do not carry over automatically. Inventory every extension element and expression in the model files, then record a Flowable equivalent or a deliberate replacement for each one. Test each process path so that a silently ignored attribute surfaces before go-live.
Operations screens with no replacement
Operations teams often depend on Camunda's web applications for incident handling, task assignment and user administration. Flowable 7.0.0 removed the UI applications from the open source distribution, so each function needs a named replacement, such as a custom task interface or a monitoring view, before cutover. Agree who performs each task during the gap and test that they can do it.
Database precision and version gaps
Migrated timestamps and history depend on the database engine version. Flowable's configuration docs note that MySQL versions below 5.6.4 lack millisecond precision, which can affect timer ordering and duration reporting. Confirm your database type and version against the supported list, then check timestamp precision on the database copy before the migration run.
Rollback never rehearsed
A cutover plan without a tested return path leaves the team choosing between a broken production system and an unplanned recovery. Rehearse the reverse procedure on a database copy: restore the Camunda 7 schema, restart the Camunda 7 application and compare instance counts with the pre-cutover record. Record how long the rehearsal takes and what must be frozen while it runs.
Scope creep into a Flowable upgrade
Moving to Flowable 8.0.0 during the engine change adds Spring Framework 7, Spring Boot 4 and Jackson 3 changes, as described in the 8.0.0 release notes. Keep the migration on a fixed Flowable target version and treat the upgrade as separate planned work. Two concurrent platform changes make it hard to tell which one caused a defect.
How the work changes by starting point
When the Camunda 7 engine runs inside your own application, the migration centers on the application code and its deployment. The engine data, active instances and history can be moved in place, but the surrounding application changes with it.
- Inventory the embedded configuration: list every process engine configuration, plugin, listener and custom job executor setting, since each one maps differently in Flowable.
- Review Java delegates and listeners: Camunda API calls inside delegates and listeners need to be replaced with Flowable equivalents and retested.
- Plan the cutover window: confirm how in-flight instances and timers will be handled while the old and new engines could both see the same data.
- Confirm the Flowable version: check the current release notes and the Java and Spring baselines of the target version before choosing a runtime.
- Confirm with Flowable: ask what the LEAP report covers for your exact Camunda 7 version and which embedded features need manual work.
Activiti shares a lineage with Flowable, so the data and model changes are often smaller than from Camunda 7. The differences that remain are in versions, configuration details and the features your application relies on.
- Map the Activiti version: identify the exact Activiti release in use, since schema and API differences depend on it.
- Compare BPMN extensions: check which Activiti-specific XML attributes and extension elements appear in your process models.
- Review history and async settings: confirm how history levels and async job configuration are set and whether they carry over unchanged.
- Test the common paths first: run regression tests on your most used process models early, because they will show the differences fastest.
- Confirm with Flowable: ask whether the in-place migration documented for Activiti data applies to your version and which items the LEAP report flags.
Flowable can be embedded as a JAR in a Spring application, a servlet container such as Tomcat or Jetty, or a Java SE application, so the runtime decides how configuration and transactions change.
- Spring applications: plan the move to Flowable Spring Boot starters, including datasource setup, auto-deployment of models and transaction boundaries.
- Servlet or Java SE applications: plan manual engine configuration, including the process engine configuration object, datasource pooling and startup and shutdown hooks.
- Check framework baselines: confirm the Spring Boot, Jakarta EE and Java versions your target Flowable release requires.
- Review scheduled and async work: confirm how the async executor starts and stops in your runtime and how jobs are distributed across nodes.
- Confirm with your team: verify which application server or container versions you run and whether they are supported with the chosen Flowable release.
When the database sits on your own servers or in a network with no outside access, the migration tooling, dependencies and test data must all be available inside that boundary.
- Confirm database type and version: check that your database is among the types Flowable lists as supported and that its version meets the documented requirements.
- Stage dependencies internally: plan how Flowable libraries, drivers and build artifacts reach the environment through your own repositories.
- Plan a database copy for testing: arrange a restored copy in an isolated network so migration rehearsals never touch production data.
- Plan backups before any run: agree how backups and restore points are taken and checked before the in-place migration starts.
- Confirm with the environment owner: ask who approves network changes, data movement and access to the migration report.
If your team uses Camunda operator tooling or other Camunda-specific operational features, those tools have no direct equivalent in Flowable and need a separate replacement decision.
- Inventory operational tools: list every operator tool, dashboard, monitoring integration and admin script your team uses day to day.
- Decide each replacement: for each tool, decide whether to rebuild it, use an existing Flowable feature or retire it, since the open source Flowable UI applications have been removed.
- Plan monitoring: map existing alerts and metrics to Flowable options, such as the actuator endpoint when using Spring Boot.
- Train operators early: schedule runbook changes and practice sessions before cutover, not after.
- Confirm with Flowable and your team: ask which Camunda operator capabilities have documented Flowable equivalents and which will need custom work.
What you need to provide
The most common reason a Camunda 7 to Flowable migration schedule moves is a missing input, not a technical surprise. Before the migration team starts, your side needs to supply read access to the BPMN models, Java code and build pipelines that run the Camunda 7 or Activiti applications, along with a current inventory of processes and the exact Camunda or Activiti version in use. Without the version, the in-place migration assessment cannot be scoped, so confirm it against the running engine rather than the project file.
Data inputs carry the most schedule risk. Provide a recent copy of the production database for rehearsal, and a list of the in-flight instance types, including which processes have active timers, message catches, asynchronous jobs and call activities. Flowable's engineering guidance says active instances and history can be migrated in place, but each instance type has to be tested against a real copy of your data. Ask your DBA to confirm the copy can be restored into a non-production environment with the same database engine and version as production.
Decisions are the other half of the list. Name business owners who can accept how each process will behave after migration, including any differences in timer handling or history, and make the call on task interfaces and identity: whether task lists stay on your current application, and whether users and groups come from the same directory they use today. Also secure a change window and written rollback approval, and confirm test and staging environment access for your team and ours. Work out these decisions in the first week, because each one that stays open blocks the rehearsal that follows.
Frequently asked questions
How long does a Camunda 7 to Flowable migration take?
The duration depends on the size and shape of your process estate, so DeployOpen scopes it in writing before work starts. The main drivers are the number of process definitions and their BPMN XML extensions, how many Java delegates, listeners and expressions depend on Camunda APIs, how many in-flight instances and how much history you keep, the number of integrations and identity dependencies, and how many environments need a rehearsal on a database copy before cutover. Ask any partner to show how each driver maps to tasks in the fixed-scope plan.
Can our own engineers migrate from Camunda 7 to Flowable alone?
Yes, a capable Java team can attempt it alone, because Flowable documents an in-place migration path for Camunda 7 and Activiti data. The work still touches data, process models and running instances at the same time. Your team needs people who understand the Camunda 7 engine, your BPMN XML and delegate code, the Flowable engine and your database operations. Many teams bring in a partner for the assessment and rehearsal runs, then keep ownership of the business logic. Decide after a written assessment of your estate.
What does the free Flowable LEAP report cover?
Flowable offers LEAP as a free tool that reports ahead of time what a migration from Camunda 7 or Activiti involves. Treat its output as one input to scoping and confirm with Flowable which elements the tool analyzes. Your own review of Java delegates, scripts, listeners and custom extensions still belongs in the plan. Because the tool carries no license fee, the cost of running it is negligible, but the effort to read its findings and act on them is part of the engagement.
Do in-flight process instances and history migrate with the application?
Flowable states that Camunda 7 and Activiti data can be migrated in place, including active process instances and history. Whether a given instance moves cleanly depends on its current state, the process definition it uses and the source engine version, so confirm each case in a rehearsal. Plan for instances that wait on removed or renamed elements, and decide whether some should finish on the old engine. History volume also affects the migration window and database load, so size it before cutover.
Must we upgrade to Flowable 8.0 during the Camunda 7 migration?
Not necessarily, but the target release decides how much else changes at the same time. Flowable 8.0.0 was released on February 27, 2026, and it moves to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. It also makes Jackson 3 the default JSON library and removes JUnit 3 and 4 support. If you run Spring Boot 3 today, a combined move adds a platform upgrade to the migration risk. Set the target version and Spring baseline in the plan and confirm the supported path with Flowable.
Does DeployOpen certify our Camunda 7 migration for compliance audits?
No, DeployOpen does not issue audit reports, attestations or certifications. Its work is to prepare systems, controls and evidence so that an independent auditor or certification body can assess them. For a migration, that can include change records, test evidence from database copy rehearsals, access control and backup records for the new engine, and a documented map of what changed in the process estate. Ask your auditor which evidence they expect before the scope is agreed.
How DeployOpen delivers this migration
DeployOpen plans and runs Camunda 7 to Flowable migrations as fixed-scope projects inside your own infrastructure, starting from a written scope. Flowable's engineering guidance describes an in-place migration path for Camunda 7 and Activiti data, including active instances and history, and the free LEAP tool reports ahead what that involves.
How we scope
- The written scope lists which Camunda 7 process applications, BPMN models and Java delegates move to Flowable.
- Flowable's free LEAP tool reports ahead what a migration involves, and that report feeds the scope.
- The fixed-scope agreement covers deliverables, cutover approach and acceptance criteria before any work starts.
How we build
- Update BPMN XML extension attributes and listener references so they resolve correctly on Flowable.
- Port Java delegates and expressions to Flowable's Java delegate API, then run them against a migrated database copy.
- Build in-flight instance handling rules for timers, async jobs and waiting tasks before the first migration run.
How we hand over
- Rehearse the in-place migration on a copy of your production database and record timing and differences.
- Compare process definitions, active instances and history before and after each rehearsal run.
- Deliver runbooks, cutover steps, rollback plan and migration documentation the team can repeat.
How we support
- Ongoing support and upgrades after cutover are available as a retainer, scoped separately from the migration.
- Ask what the retainer covers for your process models, delegates and Flowable version schedule.
- Confirm response and change terms in writing before go-live as part of the agreed support scope.
