What you can export from Camunda 8 and what you cannot
If you face a renewal, a licensing change or an exit decision, the first thing to know is that your BPMN and DMN models export as standard files, and your process history can be copied out through Zeebe exporters. Running process instances, however, usually finish inside Camunda 8 rather than move to another engine. Plan the exit around that split. Definitions are the easy part, history is a copy you can build, and runtime state is a timing question.
In plain terms, there are three layers. Definitions are the BPMN process models and DMN decision tables you deployed, and they are plain XML and DMN files you can keep in your own Git repository. History is what the engine recorded about completed and active instances. Camunda 8 ships Zeebe exporters, including the Elasticsearch, OpenSearch and RDBMS exporters, that send this data to a store you operate, where the Camunda applications read it from a secondary storage backend. Runtime state is the token position, variables and open jobs inside the Zeebe cluster. Verify with your Camunda contact which exporter and storage backend your version supports, and confirm the exported schema is one your reporting team can query.
The Camunda License v1 and the Enterprise requirement for production Self-Managed use shape when you must act, not what data you own. Check your contract dates, your support window and whether your non-production environments still run under the Self-Managed Non-Production license, because those dates set how long you can keep the cluster running while you move. Ask your team to inventory open instances by process and estimate how long each one needs to complete. Long-running processes, such as those waiting on approvals or contracts, are the ones that will force a parallel run or a cutover plan.
Which Camunda 8 data exports, by method, format and limit
This table compares each way data can leave Camunda 8, including BPMN and DMN model files, Zeebe exporters and the secondary storage backends that Camunda applications read from. Use it to see which artifact moves cleanly and which needs a plan, then confirm exporter settings and retention against your own Camunda 8 version.
| Data | Export method | Format or destination | Limit to confirm |
|---|---|---|---|
| BPMN process models | Model files kept in your source control or deployment repository | Standard BPMN 2.0 XML files | Confirm that any Camunda-specific extension elements and job type settings are documented before reuse elsewhere |
| DMN decision models | Decision files kept in your source control or deployment repository | Standard DMN files | Confirm that FEEL expressions and input or output mappings behave the same on the target engine |
| Process history, analytics | Zeebe Analytics exporter | Sent to the analytics destination configured for your cluster | Confirm which records the exporter covers and whether it is enabled in your deployment |
| Process history, relational | Zeebe RDBMS exporter | Relational database tables that Camunda applications can read as secondary storage | Confirm supported database versions and schema for your release before planning reads outside Camunda |
| Process history, search index | Zeebe Elasticsearch or OpenSearch exporter | Indexed documents in Elasticsearch or OpenSearch | Confirm index retention settings, index naming and the supported search engine version for your release |
| Running instances | No bulk export path in the supplied facts | State remains in the Zeebe engine | Plan to let instances finish in place or confirm a migration strategy with Camunda and your target platform |
Why running instances and engine state do not move as a file
Camunda 8 exporters send history out for analysis, storage and monitoring. They do not rebuild a running engine elsewhere, so active tokens, pending jobs, workers and user tasks stay in the Zeebe cluster. Each card below names one gap and the workaround teams usually use to close it.
Running process instances
Active tokens and their variables live in the Zeebe partitions, not in the exported records. A file export cannot restart a token on another engine. The usual approach is to let instances finish in place on the Camunda 8 cluster while new starts go to the replacement, then keep the cluster until the last instance completes. Ask your team to query the count of active instances by process definition version before setting a cutover date.
Pending jobs and job workers
Open jobs, retries and timers are held by Zeebe, and workers poll the cluster for them. Exported records show that a job existed, not how to resume it. Replacement services must be built to handle the same task types, or the old workers must keep running until open jobs drain. Confirm which task types are still active and whether any worker depends on Camunda client libraries.
Java code and custom integrations
Delegates, listeners, connectors and expression functions are application code, not model data. The BPMN file references them by name, and a replacement engine will not run them unchanged. Plan rewrites as service tasks or external workers, and inventory every connector and script in your models before counting the work. A BPMN diagram alone will not carry this logic.
Tasklist and Operate views
The operational screens that staff use to act on tasks and inspect instances are applications that read from secondary storage. Their saved filters, assignments and user task forms do not export as standard files. Exported history can rebuild reporting in your own tools, but open user tasks still need a destination. Decide who will complete open tasks and where they will do it before cutover.
Identity users, roles and groups
Camunda Identity holds the users, roles, groups and permissions that control access to Operate and Tasklist. These records are not part of the BPMN or DMN files and must be recreated in the target identity system. Map each role to an equivalent group in your directory, and check that task assignees still resolve after import.
History kept for reference
Exported history is useful for audit trails, reporting and dispute review, but it is a record of what happened, not a live state. Keep it in a store that your retention policy covers, such as Elasticsearch, OpenSearch or a relational database, and test that queries return the fields your reviewers need. Confirm the retention period with your compliance owner, since Camunda's documentation does not set one for you.
The sequence for a complete export, step by step
This sequence leaves you with a verified copy of your BPMN and DMN models, a backup of the process history held in secondary storage, and a documented count of definitions and instances that you can reconcile against any target system. It also makes clear when new instances must stop, so the record you export is complete.
Inventory models, versions and running instances
Start by listing every BPMN and DMN resource in use, with its deployed version, owning team and the environment it runs in. Query the cluster for active process instances, including those in incidents, and record the count per definition. Your platform or process owners should sign off on the inventory. It is done when the list covers every deployed definition and the instance counts are saved as a dated baseline you can compare against later.
Confirm exporters are enabled and writing
Check the Zeebe exporter configuration in your Self-Managed deployment and confirm which exporters are active, such as Elasticsearch, OpenSearch or RDBMS. Your platform team owns this check, since it depends on how the cluster was deployed. Verify that records are arriving by comparing recent process instance keys in the secondary storage backend with those in Operate or the API. It is done when the newest instances appear in the backend and no exporter reports persistent errors in the logs.
Freeze new process instance starts
Decide the cutover point and stop starting new instances, for example by pausing the systems that call the start API or message correlation endpoints. Let in-flight work either complete or reach a state you have documented. Your application owners make this decision, and the platform team enforces it. It is done when a fresh start attempt is refused or blocked at the integration layer and the instance count stops changing between two checks spaced apart in time.
Back up the secondary storage backend
Take a consistent snapshot of the secondary storage backend that holds exported history, whether Elasticsearch, OpenSearch or the relational database. Use the backup method your storage vendor or DBA team supports, and store the copy outside the cluster. Confirm the retention and encryption settings with your security team. It is done when a restore test on a separate environment returns the same process instance records you counted in the baseline.
Export BPMN and DMN files from the source repository
Retrieve each deployed BPMN and DMN file from the version control repository where your team keeps the models, rather than relying on exports from the modeler UI. Tag or record the commit hash for each file so it matches the deployed version in your inventory. Store the files with their version history in a location you control. It is done when every resource on the inventory has a corresponding file and a checksum that matches the deployed version.
Reconcile definitions and instance counts
Compare the counts of process definitions and process instances across four sources: the inventory baseline, the cluster API, the secondary storage backend and the exported files. Investigate any gap by definition key and version, and note expected differences, such as instances that completed before the cutover. Record the result in a signed reconciliation report. It is done when every mismatch has an explanation and a named owner, and the report is filed with the export package.
How the exporters and secondary storage fit together
The key point is that Camunda 8 does not keep process history in one place you can simply copy out. The Orchestration Cluster runs the engine, and Zeebe exporters push records from it to external systems for analysis, storage and monitoring. Camunda 8 ships Analytics, Camunda, RDBMS, Elasticsearch and OpenSearch exporters. The Camunda applications, including the operator and task views, then read the exported data from a secondary storage backend, which is Elasticsearch, OpenSearch or an RDBMS. The backend you pick therefore determines both where your history sits and what your reporting tools can query.
The diagram in the next section shows this path from the cluster through the exporter to the storage backend and back to the Camunda applications. Read it with one question in mind: which box holds the data you would need after a migration, and who runs that box. The exported copy is a separate system. Your team must operate it, size it, patch it, back it up and set its retention period under your own policy, and Camunda does not manage that copy on your behalf. Confirm with your Camunda contact which exporters your Self-Managed version supports and how the exporter configuration is maintained, because these settings change between releases.
Before you plan an export, check three things in your environment: the retention rules that apply to process records in each jurisdiction, the access controls on the secondary storage, and whether backups of that storage are tested for restore. Running instances are a separate matter. The exporters carry history, not a live state you can hand to another engine, so a migration plan has to treat the running process state and the historical records as two different workstreams.
What do buyers ask before exporting Camunda 8 data?
What drives the cost of exporting Camunda 8 data?
The main drivers are the number of BPMN and DMN models, the volume of process history, the exporter target, and how far verification goes. Export work is mostly one-time: inventorying models, configuring exporters, extracting history, reconciling it and handing it over. Recurring costs sit with the target you choose, such as the storage, hosting and support for an Elasticsearch, OpenSearch or relational database that must keep the archive readable. Model export is usually the smallest share because BPMN and DMN files are standard files. In a quote, ask for effort split by phase, the assumed target system, who pays for ongoing storage, and what is excluded, such as custom reporting or retention automation.
How long does a Camunda 8 data export take?
No fixed duration applies. Time depends on how long process instances run, how much history exists, and how fast the target accepts records. Instances that are still running usually finish inside Camunda 8, so the export of their history may need to wait for completion. A useful quote starts with an assessment of volumes per process definition and an agreed plan with checkpoints. Ask the provider to state which assumptions drive the schedule, what happens if volumes are larger than estimated, and which steps need your change windows or access approvals.
Can our own team export Camunda 8 data without a partner?
Yes, a capable internal team can export models from its repository and extract history with the exporter configuration in place. The work requires Kubernetes and database skills, access to the Self-Managed cluster, and time to test restores and reconcile counts. A partner adds planning, repeatable scripts, verification evidence and a written handover, which matter most when retention rules, personal data or audit requests apply. Many teams split the work: they own access and decisions, and the provider delivers scripts, tests and documentation under a fixed scope agreed in writing before work starts.
What access does a Camunda 8 data export need from our environment?
The export needs several kinds of access, and each should be requested early:
- Read access to the exporter target, such as the Elasticsearch or OpenSearch indices or the relational database schema.
- Access to the Helm values or configuration that define the Orchestration Cluster's exporters, so the team can confirm which exporters are active.
- Read access to the model repository, where BPMN and DMN files are stored.
- A non-production copy of the environment for test extractions and restores.
- Named owners who can approve data movement, network rules and change windows.
Confirm with your Camunda administrators whether any of these pathways are restricted by your security policy.
Which retention decisions must we make before exporting Camunda 8 data?
Decide how long each class of process history must be kept, which records fall under legal hold, which personal data can be removed before export, and who owns the archive after handover. These decisions set the scope of the export, so they should come before extraction starts. Record the decisions in writing, because auditors will ask who approved them and when. A provider can prepare the controls, evidence and runbooks that show these rules are applied, but an independent auditor or certification body decides whether your controls meet a given standard.
Does exporting Camunda 8 history move running instances to another engine?
No. Exporting history copies records out of Camunda 8 into a target you can query, but it does not transfer live process state to another engine. Running instances usually finish in place within the Camunda 8 cluster, and the export captures their history as it is written. Moving unfinished work to a different engine is a separate migration with its own strategy, testing and cutover plan. Ask whether any in-flight instances must be terminated, drained or re-started, and who approves that decision before the export begins.
How do we verify that exported Camunda 8 data is complete?
Verification compares what Camunda 8 holds with what the target stores. Typical checks include matching counts of process instances by definition and state, sampling variables and timestamps, confirming that deployed model versions are present, and recording the results with the date and the person who signed off. Agree the sampling method and acceptance criteria before extraction. Keep the reconciliation logs, because they become evidence for audits and disputes. Confirm with your provider which checks are included in the fixed scope and which are optional.
Which exporters can send Camunda 8 data to an external system?
Camunda 8 uses Zeebe exporters to send data from the Orchestration Cluster to external systems. The documentation lists Analytics, Camunda, RDBMS, Elasticsearch and OpenSearch exporters. The choice of target affects query tools, storage cost and who operates the database. Check which exporters are enabled in your deployment, and confirm with Camunda whether records produced before an exporter was enabled can be backfilled, because this determines how much history the target can hold. Zeebe exporters documentation describes the configuration options.
What to plan before the Camunda 8 contract renewal or termination
Export is only one part of leaving Camunda 8. The cards below cover the licensing position, the sequence of stopping new work, the wait for running instances, the history you keep, and the licensed environment you need until cutover is verified. Each item is a decision to confirm with Camunda and your internal legal team before you set a date.
Production licensing position
Camunda's documentation states that from Camunda 8.6 the core components are under the Camunda License v1, and that production use of Camunda 8 Self-Managed requires the Self-Managed Enterprise Edition. Non-production use falls under a separate non-production license. Confirm with Camunda and legal which license covers each environment you run today, and whether that coverage continues through the export and any parallel running period.
Cutoff for new process instances
Decide the date after which no new instances start in Camunda 8, and which channels stop starting them, such as APIs, message events, timers and start forms. Your applications may start instances from several places, so an inventory is needed before the cutoff is set. Ask Camunda and your team how a stopped start path is verified in your environment.
Time allowed for running instances
Running instances usually finish in place inside Camunda 8, so the drain period is often the longest item on the plan. Measure the longest-running instances from your own data, including timers and waiting message events that can stay open for months. Confirm with your process owners which of these can be cancelled, which must complete, and which need a separate migration path.
Retention of exported history
Process history reaches you through a Zeebe exporter to Elasticsearch, OpenSearch or a relational database, and that store must outlive the subscription. Decide how long you keep exported records, who can read them, and how they are backed up and encrypted. Check with compliance which retention periods apply to process records in your sector before deleting anything.
Licensed environment until cutover
Keep a licensed Camunda 8 environment running until the new platform has run every instance type to completion and the exported data has been checked. Ask Camunda about the terms for keeping a production environment during a transition and whether any period is included or billed separately. Plan the renewal date around this verification window rather than around the export itself.
Choosing where the exported history goes
The export target decides who can query your Camunda 8 history after you leave, so choose it by what your team already operates. Elasticsearch and OpenSearch are the two search-backed options in Camunda 8's exporter set, and they suit teams that already run a search cluster for logs or application data and know how to size, snapshot and upgrade it. The RDBMS exporter suits teams that run a relational database platform with mature backup, access control and reporting tooling, and that want process history queryable with plain SQL by finance, audit or BI tools. Confirm with your Camunda contact which exporter versions and database versions your target Camunda release supports, because the supported matrix changes between releases.
Match the target to the questions people will ask. Search-backed stores handle free-text lookups across instances, variables and incidents well, and they are a natural fit for operations dashboards. A relational store handles joins against customer, case or payment tables and gives auditors a schema they can document. Retention is the other driver: write down how many years of history you must keep, who may read it, and whether deletion must be provable. Those requirements usually cost more to meet on a search cluster that grows with every variable than on a database with a defined retention job, so ask your implementation partner to size both options against your real volumes before you commit. Test a restore of the archive as well as the export itself.
This page covers export only. Exported history stays readable after you leave Camunda 8, but running instances do not move with it, and a replacement engine needs its own plan for work in flight. For that, read the sibling migration topics on moving to Flowable and on Operaton and CIB seven, which cover model compatibility, worker replacement and in-flight instance strategy. Start the archive decision now, since the archive is the one part of the exit you can build and verify before any production process changes.
How DeployOpen scopes and delivers a Camunda 8 data exit
DeployOpen plans and implements data exits from Camunda 8 inside your own cloud accounts, data centers or air-gapped networks. We start from a written scope that separates model files, process history and running instances, so each category has a named destination and an agreed test.
How we scope
- Inventory every BPMN and DMN model, its version history and the deployment source that holds it.
- Identify which Zeebe exporters are enabled and which secondary storage backend holds the history you must keep.
- Agree in writing whether running instances finish in Camunda 8 or move to a target engine, with the cutover conditions.
How we build
- Set up the chosen target store, such as Elasticsearch, OpenSearch or a relational database, inside your environment.
- Build export and extraction scripts for models and history, with checksums and record counts for each batch.
- Test the export against a copy of production data and document every mismatch found and how it was resolved.
How we hand over
- Deliver a runbook covering each export step, its inputs, outputs, owners and rollback path.
- Provide a data map that records where each model, history table and retention rule now lives.
- Walk your operations and compliance teams through the evidence pack, so they can check it themselves.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the handover is complete.
- Retest the export when Camunda 8 versions change the exporter, schema or secondary storage behavior.
- Confirm with your auditors which evidence they expect, since DeployOpen prepares evidence but does not issue audit opinions.
