Export data from Bizagi: exit guide

How to export data from Bizagi: what you can take out

If your Bizagi renewal is approaching, your licensing terms are changing, or you plan to move processes onto your own servers, you need a clear inventory of what you can take out before access ends. Process diagrams can be exported as BPMN 2.0 XML and XPDL, but forms, business rules, data models and work portal configuration are not portable and must be documented by hand. Treat the diagram export as the starting point of the migration, not the whole of it.

Sort your inventory into three groups. The first is what exports: process diagrams in BPMN 2.0 XML and XPDL from Modeler or Studio, which carry the flow, tasks, gateways and lanes. The second is what does not export in usable form: form layouts, rule logic, the data model behind each process, users and roles, and the work portal configuration. The third is what you must document yourself: for every process, record the data fields it reads and writes, the decisions it makes, the assignment rules, the deadlines and escalations, and the integrations it calls. The exact export options depend on your Bizagi version and whether you use Modeler or Studio, so ask Bizagi in writing which formats and export paths your edition supports, and confirm what the exported files contain before you rely on them.

Run a test export on one representative process before you commit to a timeline. Open the exported XML in a BPMN-compliant modeler, compare it against the original diagram, and list every element or attribute that disappears or changes. Those gaps become your rebuild backlog. Keep the source Bizagi projects and any exported files under your own retention policy while you document, since the rebuild may take longer than the period in which you can still query the original environment.

Which Bizagi exports are documented and what each format keeps

This table lists the Bizagi items you may need to move and how each one leaves the platform. BPMN 2.0 XML and XPDL diagram exports are the starting point, but cells marked to confirm depend on your Bizagi version and should be checked with Bizagi before you plan the migration. Treat any item without a confirmed export route as content you document and rebuild by hand.

Item	Export route	What it keeps	What it drops or limits
BPMN 2.0 XML from Modeler	Diagram export from Bizagi Modeler, confirm menu path	Process shapes, sequence flows and standard BPMN elements, to confirm	Bizagi-specific attributes, forms, rules and data model, to confirm
XPDL from Modeler	Diagram export from Bizagi Modeler, confirm menu path	Diagram structure, to confirm	Confirm XPDL version written and any element loss on re-import
BPMN 2.0 XML from Studio	Export from a Studio project, confirm scope	Process diagrams, to confirm	Confirm whether export covers one process or the whole project
XPDL from Studio	Export from a Studio project, confirm availability	Process diagrams, to confirm	Confirm whether this format is offered for Studio projects
Process data and attributes	Not a diagram export, confirm any data export option	Confirm whether attribute definitions can be exported	Document entity fields, types and defaults by hand if no export exists
Forms and screen layouts	Confirm whether any form definition can be exported	Confirm whether field layouts are retained	Expect rebuild in the new UI, record field rules and validations manually
Business rules and decision logic	Confirm whether rules export in any standard format	Confirm whether decision tables are retained	Record each rule, its inputs and outputs as a DMN-style table by hand
Organization model, roles and users	Confirm whether directory or role data can be exported	Confirm whether roles and assignments are retained	Document role mappings and escalation paths before cutover

What does not leave Bizagi and how to rebuild it

BPMN 2.0 XML and XPDL carry the process diagram, but most of what makes a Bizagi application work sits outside those files. The cards below cover the items that do not export as portable artifacts, how to capture each one before you leave, and what the target engine will need built to replace it.

Form layouts and UI

Bizagi forms, screen layouts, field placement, validation messages and button behavior are defined in the Studio and do not travel in BPMN XML. Capture each form with screenshots at every state, and write down the field list, types, default values and visibility conditions for each task. Check which forms were shared across several processes, because each one must be rebuilt once in the target. In Flowable or Operaton, your developers will build the task UI, usually as a separate front end or as Flowable's own task forms, so budget for that build explicitly.

Business rules and decision logic

Rules embedded in Bizagi expressions, decision tables and calculated fields do not appear as DMN unless someone converts them. Export each rule table by hand into a spreadsheet, record the inputs, outputs, hit policy and any edge cases, and test sample cases against both systems. Expressions in gateways and script tasks need the same treatment. Flowable and Operaton can run DMN 1.3 decision models, but the rules must be written and tested again in that format.

Data model and entity definitions

The Bizagi data model, including entities, attributes, relationships and data types, lives in the Studio project and is not part of the BPMN export. Document each entity with its attributes, keys, required fields and relationships, then map them to database tables in the target. Process variables in BPMN keep only what the engine stores, so anything that lived in the data model must become a database schema, an API or a separate service. Ask your Bizagi administrator who owns that schema and which systems read from it.

Work portal configuration

The work portal, with its menus, dashboards, queues, filters, notifications and branding, is configured in Bizagi and does not transfer. Record each queue, its selection criteria, the columns shown and the actions available, and list the notification triggers and email templates. Engines such as Flowable and Operaton expose task and process APIs but do not ship an equivalent portal, so plan for a task list and monitoring view. CIB seven includes a task list, but you still need to confirm it matches your queue logic.

Users, roles and assignments

Users, groups, roles and the rules that assign tasks to them are stored in Bizagi's directory and organization model. Export the user and role lists from your directory service, then document each assignment rule in plain language, including escalation and delegation. Flowable's identity service can be replaced or implemented against your own directory, and it provides an LDAP reference implementation, so confirm how your identity source maps to the groups used in each process.

Running case data and history

Cases that are open at cutover hold state, variables and audit history that a BPMN diagram export does not carry. Decide which open cases finish in Bizagi, which are restarted in the new engine, and which need their data copied across. Pull case records through any documented Bizagi interface you have licensed, and keep archived history in a read-only store for audit. Confirm retention and legal hold requirements before deleting anything, and test that the old and new processes can run side by side until the last case closes.

Export sequence and verification before access ends

This sequence turns a Bizagi estate into a documented, verified archive of diagrams, forms, rules and data definitions that you control before cloud access or licensing changes end your ability to export. Each step closes with a check you can repeat, so the business owner signs off on evidence rather than on memory.

Inventory every process, version and owner
Start with a complete list of every process model, subprocess, active version and archived version in your Bizagi environments, with the business owner, the Modeler or Studio version used to build it, and the environment it runs in. Record which processes have open cases, because those cases need a cutover plan rather than a diagram export alone. Check: the inventory matches the model count shown in the repository, and every row has an owner and a version number.
Confirm export options for each tool version
Before exporting, check which export formats your specific Modeler or Studio version offers for BPMN 2.0 XML and XPDL, and test the export on one representative process from each version. Ask Bizagi to confirm in writing which formats are available in your cloud tenant and whether any option has been removed. Check: a test export opens without error, and you have noted any format that is missing for a given version.
Export diagrams in BPMN 2.0 XML and XPDL
Export every in-scope process to BPMN 2.0 XML and, where you need the original Bizagi structure, to XPDL, keeping one file per process version. Do not overwrite earlier exports. The export team should record who ran each export and when. Check: the file count matches the inventory, and each file name carries the process name, version and export date.
Store exports with version and date metadata
Place the exported files in a repository you control, with a manifest that lists process name, version, format, export date, exporting user and a SHA-256 checksum for each file. Keep the original source files together with the exports so that a future reader can compare them. Check: recalculating a checksum on a sample of files returns the value in the manifest.
Document forms, business rules and data model fields
BPMN exports carry the flow, but forms, decision rules, data entities, field types, validations and integration calls are typically not complete in a diagram file. Write a specification for each form, each rule with its inputs and outcomes, and each data field with its type and where it is used. Confirm with developers which items cannot be read from the export. Check: every task that references a form or rule in the diagram has a matching entry in the specification.
Run a verification pass against the originals
Open each BPMN file in an independent BPMN tool, not in Bizagi, and compare the count of tasks, events, gateways, pools and lanes with the original process. Record any mismatch, including dropped extended attributes, lost labels or changed lane assignments. Check: each file's element counts and lane names match the original, and every mismatch is logged with a decision on how it will be rebuilt.
Obtain sign-off from the business owner
Give each business owner the manifest, the verification log and the documented gaps for their processes, then ask them to approve in writing that the exports and specifications represent the process they own. Keep the signed record with the archive. Check: every process in the inventory has a signed approval, and open gaps are assigned to a named owner before access to the Bizagi environment ends.

What BPMN 2.0 XML keeps and what it drops

BPMN 2.0 XML keeps the standard process structure: tasks, events, gateways, sequence flows, pools and lanes. A BPMN engine can read these elements and execute the control flow they describe, so the diagram logic itself is the most portable part of a Bizagi export. Treat that as the baseline you can rely on, not as proof that the process will run unchanged. The structure carries the flow of work, but almost none of the business meaning that Bizagi users added around it through their own modeling conventions.

Bizagi-specific extended attributes, form bindings, service configurations, data mappings and script details are the parts most likely to be dropped or stored in a Bizagi-specific way that a standard engine will not interpret. Before you export anything, build an inventory from the source models in Modeler and Studio: every task with a form or rule attached, every data object and its type, every timer, message or service call, and every script or expression. Record each item in a spreadsheet with its process name, element ID and target owner, because these are the items you will re-add by hand in the target engine.

Export one representative process and compare the resulting file against the original in both Modeler and Studio before you rely on the export for the full portfolio. Check that element IDs, names, lanes and sequence flows match, and open the XML to see which extension elements survived. Confirm with Bizagi, in writing, how each export format handles the attributes in your inventory and whether any element type is stored outside the BPMN file, since that behavior can change between product versions.

Exporting from Modeler versus Studio

Models maintained in Bizagi Modeler are the most portable starting point, because the diagrams are the artifact most likely to leave the product as standard BPMN 2.0 XML or XPDL. Confirm with Bizagi which export options your installed Modeler version offers and whether export runs per process or per package, since that determines how many files you will handle.

Format choice: Export each process to BPMN 2.0 XML for engines such as Flowable or Operaton. Keep an XPDL copy only as a reference for the Bizagi-specific constructs it carries.
Extended attributes: Expect shapes, sequence flows, pools, lanes and gateways to survive. Plan to re-add the Bizagi-specific properties, expressions and data bindings that a standard BPMN file does not carry.
Versioning: Record the Modeler version and the model version for each file, so reviewers can match a diagram to the process that was running.
Separate documentation: Write down activity descriptions, time limits, escalation rules and role assignments that exist only as model properties.

Before leaving, open one exported file in the target engine's modeler and confirm which elements arrive intact.

What to plan before the Bizagi contract renewal or termination

Bizagi exports only go as far as your access and contract allow, so the export sequence should start with the commercial calendar. The cards below cover the decisions that set the window, the scope and the owners before any diagram leaves the platform.

Confirm the contract end date and notice

Read the end date, renewal terms and notice period in your Bizagi agreement before scheduling anything else. The notice deadline, not the end date, usually sets when you must decide. Check whether access ends on the contract date or a grace period later, and whether the cloud PaaS subscription auto-renews. Every other step in the export sequence depends on this date.

Set the export window while access is active

Plan a fixed period, before access closes, in which you export every model, form definition and rule set you need. Ask Bizagi in writing how long read access continues after termination and whether it covers Modeler and Studio. Exports taken late in that window leave no room to fix a failed file, so schedule a second pass.

Map data retention and deletion obligations

Process instances, case data, attachments and audit history may fall under your own retention rules or contractual terms that apply to Bizagi as your processor. Ask Bizagi what it deletes, when and how it certifies deletion. Decide which records you must archive before the platform is cleared, because a BPMN file carries none of that runtime data.

Get Bizagi's written list of permitted exports

Ask Bizagi to confirm in writing which artifacts you may take out: BPMN 2.0 XML and XPDL from Modeler and Studio, and whether form definitions, business rules and data models are included. Some vendor material may carry license or confidentiality restrictions. Keep that confirmation with the contract so the migration team works from an approved scope.

Decide the target engine and hosting

Choose the engine and where it runs before the export starts, since that decides which BPMN extensions you need to document. Flowable and Operaton both run BPMN 2.0 models, and Flowable also adds CMMN and DMN engines. Decide whether the new platform sits in your cloud account, a data center or an air-gapped network, because that drives the export destination.

Name the internal sign-off owners

Assign one owner each for business sign-off on process inventories, IT for storage and access of exported files, security for data handling and deletion evidence, and legal or compliance for the contract and retention decisions. Agree who approves the final export set. Without named owners, the exported files sit in storage and the cutover date slips.

Where exported models can go next

A self-hosted target can read the BPMN 2.0 XML you export, but reading a file is only the first step. Flowable is an Apache-2.0 Java engine that supports BPMN, CMMN and DMN, exposes Java and REST APIs, and lists PostgreSQL, MySQL, Oracle, SQL Server, DB2 and H2 as supported database types. Operaton is an Apache-2.0 BPMN 2.0 engine whose 2.1 release notes state compliance with DMN 1.3 and CMMN 1.1, with supported databases including PostgreSQL, MariaDB, MySQL, Oracle, SQL Server and DB2. Confirm which of these standards each candidate actually needs for your exported files, because Bizagi's diagram output and your case models may not use all of them.

A BPMN file that imports cleanly is not the same as a process that runs. Import checks the notation, not the behavior. Bizagi-specific data objects, form bindings, business rules, user assignments and connector calls do not carry across as working logic, so each one needs to be rebuilt and tested in the target. Plan a test pass for every gateway condition and every task that depends on a form or a rule, and use a small set of real historical cases to compare outcomes between the two systems before any cutover.

Choosing the engine is part of migration planning, not part of the export. Decide early whether your team can own a code-first engine, how you will supply forms and a task interface, and which database and hosting model your security and residency requirements allow. Ask each candidate's maintainers or service providers to confirm support terms, upgrade cadence and the Java and database versions they test against, since those decisions shape what you export and how much you must rebuild.

Questions buyers ask before exporting data from Bizagi

Can we export our Bizagi processes without outside help?

Yes, the diagram part is within reach of an internal team with Bizagi access. Modeler and Studio can export process diagrams as BPMN 2.0 XML and XPDL, so a team can produce the files itself. The harder part is what those files do not carry. Forms, business rules, data model definitions, user and role assignments and integration settings usually need to be documented by hand from Bizagi and rebuilt on the target engine. Whether your team can do that alone depends on how many people know the current solution and whether they have time to document it while it stays in production.

What makes the export effort grow or shrink?

The effort is driven by the inventory and the condition of the models, not by the export itself. The main drivers are:

The number of processes and subprocesses in scope
How many forms, data entities and business rules each process relies on
How many integrations, web services and scheduled jobs call into Bizagi
Whether the diagrams are current, consistently named and free of abandoned versions

A clean, well-documented set of models with few integrations is far less work than a large estate where the logic lives partly in forms and rules. Ask for a written inventory before agreeing on scope, since that inventory sets most of the work.

How long does exporting and documenting Bizagi processes take?

The time depends on the same drivers as the effort: the number of processes, the complexity of their forms and rules, the number of integrations, and how current the models are. Documentation of forms and rules often takes longer than the diagram export, because each rule has to be read, confirmed with its owner and written in a form the target engine can use. No duration is given here because none has been researched for this migration. Ask your provider to break the timeline into inventory, documentation, rebuild and parallel run, and to tie each phase to a named deliverable.

What does the work need from our team?

The work needs three kinds of people in place. First, access to Bizagi, including the ability to export diagrams and read forms, rules and data definitions. Second, business owners who can confirm what each process is supposed to do, approve the documented rules and sign off on the rebuilt behavior. Third, a technical owner for the target platform who makes decisions about hosting, database, identity and upgrades. Without the business owners, documented rules tend to be guesses. Without the technical owner, the export has nowhere to land. Confirm named people for each role before work starts.

Do we need a service provider, and what should the written scope cover?

A provider is not required, but it helps when the inventory is large or when no one internal has time to document it. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A written scope should list the processes in scope, the export formats used, the forms and rules to document, the integrations to re-create, the target engine and version, the database and hosting model, testing and sign-off steps, and what happens to running cases. Ask for the scope to state what is excluded as clearly as what is included.

What happens to running cases at cutover?

Running cases do not move automatically with a diagram export. A BPMN 2.0 file describes the process model, not the state of each open case, so instances in flight in Bizagi need a separate plan. Common approaches are to let open cases finish in Bizagi while new cases start on the new engine, or to migrate selected cases by hand where their state can be mapped. Running old and new processes side by side until open cases close is the usual way to limit risk. Confirm with your provider how open cases will be counted, mapped and reconciled before cutover, and keep Bizagi access available until the last case closes.

Will the exported diagrams run unchanged on an open-source engine?

Not usually without review. BPMN 2.0 XML is a standard format, so the core flow of tasks, gateways and events generally carries across. However, Bizagi-specific extended attributes, form bindings and rule references are typically dropped or left unresolved in a standard export, so they must be re-added. Check each diagram against the target engine by deploying it to a test environment, and confirm which BPMN elements your chosen engine supports. Treat the exported file as the starting point for the rebuild, not the finished process.

How DeployOpen scopes and delivers a Bizagi export

DeployOpen plans, implements, documents and hands over self-hosted open-source process platforms inside your own infrastructure. For a Bizagi export, we start with an inventory of what the diagrams, forms, rules and data actually depend on, then deliver the export package in writing before any migration work begins.

How we scope

Inventory of Bizagi models, exported formats and the extended attributes each process relies on
Written list of forms, business rules, data objects and integrations that must be documented by hand
Fixed-scope agreement covering deliverables, timelines and acceptance criteria before work starts

How we build

Export BPMN 2.0 XML and XPDL from Bizagi, then check each file against the source model
Rebuild the extended attributes and rule logic that the exported diagrams do not carry
Test exported processes on a self-hosted Flowable or Operaton environment inside your own network

How we hand over

Documentation of every exported model, mapping table and open gap, with the reason for each
Runbook for deployment, database setup, backup and upgrade of the self-hosted engine
Side-by-side test results and a list of processes still needing business owner sign-off

How we support

Ongoing support, upgrades and continuous testing available as a retainer after handover
Review of each engine upgrade against your exported models and custom code
Support scope confirmed in writing, so your team knows who handles which change

How to export your processes from Bizagi