Migrate from Bizagi to Flowable

Migrate from Bizagi to Flowable: what moves and what you rebuild

BPMN 2.0 XML exports carry the process diagrams across, but the forms, business rules, data model and work portal must be rebuilt by developers. That split is the core of this migration. If your Bizagi estate can no longer be licensed on premises, or you want to leave a cloud PaaS dependency, plan for a rebuild of everything that Bizagi kept inside its own platform, not a file transfer. Flowable's engines for BPMN, CMMN and DMN are Apache-2.0 licensed, so the execution layer carries no license fee, and its commercial editions (Flowable Work, Engage, Orchestrate and Design) are optional add-ons that you can evaluate separately.

Internal platform or application teams usually own this work, often with an implementation partner for the engine setup, the Spring or Java integration and the first wave of cases. Expect the effort to be concentrated in the non-diagram parts. Each Bizagi process needs its data entities mapped to a relational schema in one of the databases Flowable supports, each user form rebuilt as a web front end because Flowable's open-source edition does not include the UI applications removed in version 7, and each decision table re-expressed as DMN. Confirm with your Bizagi administrators which rules run inside the diagram and which live in entities or scripts, because that split decides how much of the work is modeling and how much is code. Risk is moderate and mostly concentrated in forms and data, not in process logic.

Plan for the work portal early. Bizagi gives business users a task inbox, and Flowable's open-source engines expose Java and REST APIs but leave the task interface to your developers. Decide whether that inbox is built on your existing intranet, a new single-page app or a commercial add-on, and confirm how identity will be supplied, since Flowable's docs describe replacing identity management through an interface, with an LDAP reference implementation provided. Keep the old and new processes running side by side until in-flight cases close, and route new cases to Flowable only once the rebuilt forms pass acceptance testing. Review the Flowable open source documentation and your Bizagi export inventory before you size the rebuild.

Which Bizagi capabilities map to Flowable, and where the gaps are

This table maps each Bizagi capability to its Flowable equivalent and marks it as clean, needs rework or gap. Read the status column first: clean means the engine covers the capability directly, needs rework means you rebuild it in code or configuration, and gap means nothing in the open-source engines provides it and you must build or buy it. The main takeaway is that Flowable supplies the execution layer, while the user-facing layer is largely yours to build.

Bizagi capability	Flowable equivalent	Status
Process modeling	BPMN 2.0 models authored in external modelers, deployed to the BPMN engine	Needs rework
BPMN process execution	BPMN engine with Java and REST APIs, embeddable or run as a service	Clean
Case management	CMMN engine for case models, separate from BPMN process execution	Needs rework
Business rules	DMN engine for decision tables, called from BPMN and CMMN models	Clean
Data objects and data model	Process variables and your own database schema, designed and migrated by hand	Needs rework
Forms and UI	No UI applications or form engine in Flowable 7.0.0 or later, so a custom task UI is required	Gap
Work portal and task inbox	No built-in work portal, so you build the task list on the REST APIs	Gap
User roles and identity	Identity management can be replaced through a service interface, with an LDAP reference implementation	Needs rework
Reporting and process monitoring	Engine history tables and the Spring Boot actuator endpoint, with dashboards built by your team	Gap

What data and integrations you must move by hand

Bizagi migrations rarely stall on the diagrams. The harder work is the data, identities and integrations that sit around them, and none of it moves through a single export. Treat each of the four streams below as its own workstream with an owner, a test and a sign-off before any case is switched over.

BPMN diagrams from the export

Export each process model as BPMN 2.0 XML using only the export path Bizagi documents, then open every file in a Flowable-compatible modeler and deploy it to a test engine. The export keeps the flow structure, but extended attributes such as custom properties, task assignments and form bindings may be dropped, so compare each exported model against the original in Bizagi element by element. Record every attribute you re-add by hand so the work is auditable.

In-flight case data and attachments

Cases that are open on the day of cutover carry field values, document attachments and history that the BPMN file does not contain. Decide per process whether these cases finish in Bizagi or move, because moving a running instance means mapping its variables to the new data model and copying the files to storage you control. Ask the team that owns each process which cases must survive, and confirm attachment sizes and retention rules before you plan the copy.

User and role mapping

Bizagi users, roles and group assignments must map onto the identity service Flowable uses for candidate groups and task ownership. Flowable documents that its identity management can be replaced by overriding the identity service implementation or by implementing the identity service interface, and it provides an LDAP implementation as a reference. Confirm which directory is the source of truth, and test that a reassigned task still reaches the right people after the switch.

Web service and database integrations

Bizagi wires calls to web services and databases through its own connectors, and those connections do not travel with the BPMN file. Inventory every service task and its endpoint, credential, payload and error handling, then rebuild each one as Java delegates or REST calls that run in your infrastructure. Store credentials in your secrets manager, not in the process model, and test failure paths such as timeouts and partial responses before go-live.

Only documented export paths

Use only the export formats Bizagi documents for its Modeler and Studio products, and avoid scripts that read Bizagi's internal storage directly. Undocumented extraction may miss data, break on version changes and create unclear provenance for the migrated records. Keep the export files, their checksums and a dated log of what each export contained as evidence for the cutover.

Migration sequence from inventory to decommission

This sequence moves Bizagi processes to Flowable one case type at a time, so each step ends with a verified output and open cases finish on the system where they started. Bizagi stays available for reference until the last archive is confirmed.

Inventory processes, forms, rules and open cases
Your business analysts and Bizagi administrators list every process model, form, business rule, data object, integration endpoint and user role in scope, then record the number of open cases per process. Integration owners confirm which external systems each process calls and which ones call back into it. The step is complete when the inventory is signed off by the process owners and every open case is assigned to a case type, so nothing is left unmapped before rebuilding begins.
Rebuild a pilot process on Flowable
Choose one low-risk process with few integrations and export its diagram as BPMN 2.0 XML. Re-add the extended attributes the export drops, deploy the model to a Flowable engine, and expose it through the Flowable REST API. For testing, the engine can run on H2, while production should use a supported database such as PostgreSQL, configured and backed up under your own database standards. The step is complete when the pilot runs end to end in a test environment and its results match the Bizagi output for the same inputs.
Rebuild forms, rules and the data model
Developers rebuild the forms in your front-end layer, implement each decision rule as DMN where it fits or as code where it does not, and recreate the data tables that Bizagi held internally. Testers compare each rebuilt form and rule against the documented Bizagi behavior using agreed test cases. The step is complete when every pilot test case passes and the process owner accepts the screens, decisions and data fields as equivalent for the pilot scope.
Run old and new processes in parallel
Configure routing rules so that new cases of the pilot type start in Flowable while cases already open stay in Bizagi. Operations staff compare outcomes, task timings and audit records between both systems each working day and log every discrepancy with its root cause. The step is complete when the discrepancy log has no open defects and the process owner signs off the Flowable results for production use.
Cut over by case type
Move each remaining case type to Flowable in turn. New cases route to Flowable from the cutover date, and Bizagi keeps the open cases until they close naturally or are reassigned under a documented procedure. Users confirm their task lists and integrations in the new system before the next case type moves. The step is complete when Bizagi reports zero open cases for every migrated case type.
Decommission Bizagi and archive its data
Export the final process history, audit logs, case records and document attachments from Bizagi, store them in an archive that meets your retention policy, and confirm that a designated owner can retrieve them. Revoke Bizagi licenses or subscriptions according to your contract terms, remove integrations, and update the configuration management database. The step is complete when the archive has been restored and tested once, and the Bizagi environment is formally closed with written sign-off from the business and IT owners.

What drives migration cost and duration

This table lists the factors that change how much work a Bizagi to Flowable migration takes and how long it runs. Read each row as a question to answer about your own estate before asking for a quote, since the largest drivers are usually counts you can measure now.

Driver	Why it changes effort	How to keep it down
Number of processes	Each live process needs its BPMN model converted, tested and re-attached to its owners, so the count sets the bulk of the rebuild.	Retire processes with no recent instances before export, and merge near-duplicates into one parameterized model.
Form count and layout	Bizagi forms do not carry over in the BPMN export, so every form must be rebuilt in your chosen UI layer, and shared forms multiply the work.	Standardize on a smaller set of reusable form templates and confirm early which front end your team will maintain.
Business rule complexity	Rules held in Bizagi decision tables or expressions must be re-expressed as DMN tables or code, and rules that depend on other rules take longer to verify.	Inventory rules by owner and retire stale ones, then move stable rule sets to DMN with test cases for each outcome.
Custom Bizagi scripting	Scripts embedded in activities and data rules are not portable, so each one needs a Java or service equivalent and a review of its side effects.	List every script, group them by purpose, and replace repeated patterns with a shared service class.
Integration count	Each connector to a system of record, mail server or document store needs new code, credentials and error handling in Flowable.	Confirm which integrations are still in use and route them through one integration layer rather than point-to-point calls.
Data model size	Bizagi entities and their relationships must be mapped to relational tables, and historical data decisions (migrate, archive or stop) add scope.	Decide per entity whether open cases need the data, and archive closed-case history outside the new engine.
Open case volume	Running cases must finish on the old system or be moved with their state, and the number of in-flight instances sets how long both systems stay live.	Ask Bizagi administrators for open case counts by process and set a cut-over rule that lets old cases drain.
Hosting target	Self-hosting in your own cloud, data center or air-gapped network adds database provisioning, clustering, backup and patching that the Bizagi cloud subscription currently covers.	Choose the hosting model and database engine early, and confirm which Flowable database types your standards allow.
Identity integration	Bizagi users, roles and groups must map to your directory, and Flowable identity management is replaced through its identity service interface, which takes development and testing.	Map roles to directory groups before migration, and confirm whether an LDAP-based identity service fits your directory.
Timers and asynchronous jobs	Timers and deadlines in running processes must fire exactly once across nodes, so cluster behavior needs testing, not just configuration.	Rely on the async executor's lock owners and lock expiration in the database for cluster-safe timer handling, and test failover on a non-production cluster.

How the migration differs by starting point

A small estate is usually a few approval flows, such as purchase requests, leave approvals or access requests, each with a short form and a simple routing rule. The migration is mostly a modeling and testing exercise. Export the BPMN 2.0 XML, confirm that the diagrams deploy to Flowable, and rebuild the forms and decision tables by hand. Because volumes are low, cutover can be planned around a short window in which open cases are closed on Bizagi while new cases start in Flowable. Illustrative example: a team with four approval flows might rebuild them in a single sprint and test them against recorded cases from the last quarter.

Scope: Flowable's open-source edition provides the BPMN, CMMN and DMN engines and REST APIs, so you will need a small front end or a task list that your developers build, since the engine itself has no work portal.
Parallel run: Keep Bizagi live only until in-flight cases close, and record which cases were started in each system.
Evidence: Keep a short register of each process, its approvers and its decision rules, signed off by the process owner.
Staffing: A few developers can cover the work, but someone must own the Java and Spring Boot skills after go-live.
Retirement: Confirm the Bizagi exit date and archive the exported diagrams and sample cases before you remove access.

Check with your Bizagi contract team what export and retention rights apply to your subscription before you rely on the export files.

What usually goes wrong and how to prevent it

Most Bizagi-to-Flowable migrations stall for the same reasons: information that never made it out of Bizagi, work that was underestimated, and ownership that was never assigned. Each card names one risk and the check that keeps it from reaching production. Review them before the cutover plan is signed off.

Extended attributes lost in export

A BPMN 2.0 XML export carries the flow, but Bizagi-specific extended attributes such as form bindings, data mappings and custom properties may not survive the trip. Compare each exported diagram against the source in Bizagi and list every element whose behavior depends on information missing from the XML. Re-add those attributes in Flowable and test each one with a sample case before you rely on the model.

Form rebuilds underestimated

Bizagi forms, their field validations and the work portal screens that users see are not part of a BPMN export. Flowable's open-source edition ships engines and REST APIs without the UI applications, so each form needs a replacement built by your developers. Inventory every form and screen early, then size the rebuild as a separate work package rather than a side task of the process rebuild.

Rules living in undocumented code

Routing decisions, due-date logic and approval thresholds often sit in Bizagi scripts or expressions that nobody wrote down. Before migration, document each rule with its inputs, outputs and owner. Where a rule is a decision table, move it to DMN and test it against historical cases. Keep a register so that each rule is either migrated, retired or deliberately redesigned.

Cases stranded at cutover

Cases that are open on the day you switch can end up in neither system, or be restarted from the beginning. Decide per process whether running cases finish in Bizagi, are restarted in Flowable, or are migrated by a scripted mapping. Set a freeze date for new starts, confirm that each open case has a home, and reconcile counts in both systems before closing Bizagi access.

Identity mismatches across systems

Task assignments in Bizagi refer to users, roles and groups that may not match the directory Flowable uses. Flowable lets you replace the identity service with your own implementation or an LDAP reference implementation, so decide which directory is authoritative first. Map every assignee and candidate group, then test that tasks reach the same people after migration.

Database precision on older MySQL

The Flowable configuration docs note that MySQL versions below 5.6.4 lack millisecond precision, which can distort timer and due-date behavior. Confirm your MySQL version before choosing that database, and run timer and SLA tests with realistic durations in a staging environment. Prefer PostgreSQL or another supported database where your standards allow it, and record the choice in the architecture document.

How to run Bizagi and Flowable side by side until cases close

The parallel run works when routing is decided per process, not per user. Start by listing each Bizagi process and marking it as cut over, held in Bizagi, or split by case attribute, such as a case type or start date. New cases of a cut-over process start in Flowable, while cases already open in Bizagi finish there. Write the cutover criteria down before the first new case starts in Flowable: the process versions covered, the minimum number of cases completed end to end, the reconciliation tolerance between the two systems, and the named approver who signs off. Reporting then has to read from both sources. Build a single view that pulls open and closed cases from Bizagi's reporting data and from Flowable's history tables, mapped to a common case identifier, so that managers do not see a process as finished in one system and open in the other.

Monitor Flowable through the actuator endpoint at /actuator/flowable when the engine runs under Spring Boot, as the Spring Boot documentation describes. Use it to watch running process instances, and feed the same figures into your existing alerting. Pair it with database-level checks on the job tables, because the async executor coordinates nodes through lock owners and lock expiration times stored in the database. Stale locks or a growing backlog of jobs usually show up there before they show up in case delays. Confirm with your platform team which metrics your version exposes, since the endpoint's contents depend on the engine and starters you deploy.

Test the rollback path before the first production cutover, not after a failure. For each cut-over process, rehearse these steps: stop new routing to Flowable, confirm which cases are in flight there, decide whether they finish in Flowable or are moved back, and verify that Bizagi still accepts new starts for that process. Include a case that spans the cutover date, a timer that fires during the switch, and a user task reassigned while routing changes. Record how long each step takes in your own environment, since no duration for this work is established here. Keep Bizagi's process definitions and its data until the criteria are met and the rollback window you agreed has passed.

Questions buyers ask before migrating from Bizagi to Flowable

How much does a migration from Bizagi to Flowable cost?

No single figure applies, because cost follows the work in scope. The main components are the Bizagi subscription you keep paying until cases close, the rebuild of forms, business rules and the data model, the hosting you provide for Flowable, developer time for a code-first engine, and support. Flowable's engines are Apache-2.0 licensed, so the open-source engine itself carries no license fee, while Flowable's commercial editions and professional services are priced separately. Ask Flowable and any implementation partner to quote each component, and ask Bizagi for the exact end date of your current subscription so the overlap period is costed.

How long does a Bizagi to Flowable migration take?

The timeline depends mostly on how many processes you have, how many forms and business rules each one uses, and how many integrations must be rebuilt. Processes with simple flows and few forms move faster than those that depend on Bizagi's work portal, custom data objects or rules embedded in the diagram. Running old and new processes side by side adds time at the end, because open cases must finish in Bizagi before you can retire it. Agree a written scope with milestones before work starts, and ask any partner to tie the timeline to a named list of processes.

What does our internal team need to contribute?

Your process owners need to confirm how each process should behave, including exceptions, approvals and service levels. Developers need to rebuild the parts Flowable does not provide in the same way, such as forms, user interface and data model. Identity administrators need to decide how users and groups map to Flowable, since the Flowable docs describe replacing identity management through an identity service and provide an LDAP reference implementation. Plan for a named owner on your side who can approve decisions quickly, because delays in those decisions usually drive the timeline more than the engineering work.

Can our own team migrate from Bizagi to Flowable without outside help?

A team with Java and BPMN experience can do it, but the work is more than redrawing diagrams. Flowable is a code-first engine with Java and REST APIs, so you will write and maintain application code for forms, rules and integrations. Engineers who know Bizagi's low-code tools will need to learn BPMN, CMMN and DMN execution details. Outside help is most useful for the first process, for hardening and for production operations, and it can be scoped as a fixed engagement with written deliverables.

Is Flowable's open-source edition enough for a work portal?

The open-source edition provides the engines and REST APIs, but it does not provide the low-code modeling, visual debugging, monitoring and governance tools that Flowable sells in its commercial products such as Flowable Work. Flowable's open source page notes that open-source users receive a community forum, with professional services and partners offered separately. If Bizagi's work portal is central to your users, you will need to build or select a user interface, and the Flowable 7.0.0 release notes say the UI applications and form engine were removed from that version. Confirm with Flowable which edition covers your portal needs before you commit.

What does the Bizagi export not keep?

The BPMN 2.0 XML export carries the diagram structure, but Bizagi-specific extended attributes, forms, business rules and data model definitions are not reliably carried into Flowable. You must re-add those attributes, rebuild forms and rules by hand, and recreate the data model in your own database schema. Check each exported file against the original diagram, and document the process data and rules before you leave Bizagi, since the export does not replace that documentation. Confirm the exact export behavior with Bizagi, because it can change between product versions.

How do we run Bizagi and Flowable side by side safely?

Route new cases to Flowable only after the migrated process passes testing, and leave cases already running in Bizagi to close there. Keep both systems under monitoring, and reconcile counts and statuses between them daily during the overlap. Flowable's async executor coordinates multiple nodes through lock owners and expiration times in the database, so plan database capacity and node configuration before go-live. Set a retirement date for Bizagi only after the last open case has closed and the data you must keep has been archived.

How DeployOpen scopes and runs a Bizagi to Flowable migration

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Bizagi to Flowable move, that means the Flowable engines, their database, the REST layer, the identity integration and the surrounding backup and monitoring all run in your cloud account, data center or air-gapped network. DeployOpen does not host the platform for you and does not operate it from outside your environment. Before any work starts, the first decision is who owns each part of the target stack, because that determines who patches the engine, who restores the database and who answers when a timer job stops firing.

Most engagements are fixed-scope. The scope, deliverables and timelines are agreed in writing before work begins, and that document should list the Bizagi processes in scope, the forms and business rules to rebuild, the data entities to move, the cutover criteria and the side-by-side period. DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move cost are the number of processes, how many forms and rules need rebuilding by hand, how many identity sources and downstream systems are integrated, and whether the client needs the platform hardened or documented to a particular internal standard. Ask for the quote to separate one-time migration work from recurring items, and to name who performs each task. Ongoing support, upgrades and continuous testing are available as retainers, which are usually a better fit for the period after cutover than an open-ended project.

Migrate from Bizagi to Flowable