Bizagi vs CIB seven: when a self-hosted engine with a task UI fits
A Bizagi customer whose on-premises license has ended and who must keep processes on their own servers has a narrower choice than it first appears. Bizagi remains the better fit when the organization wants business analysts to model and change processes visually, wants forms and a work portal included, and accepts a managed cloud PaaS as the home for those processes. CIB seven fits when the requirement is self-hosting and an engine the organization owns, with BPMN 2.0 models compatible with Camunda 7 and a built-in task list, process monitoring and user management that do not depend on Camunda's Tasklist or Cockpit. It is a code-first engine, so the modeling and screens that Bizagi provided become work your team builds or buys.
The decision turns on three things. The first is forms and data model effort: Bizagi's forms, business rules and data model do not transfer with the BPMN diagrams, so inventory them before comparing platforms. The second is developer capacity: CIB seven runs inside the Java Virtual Machine and expects Java developers to maintain processes, delegates and integrations. Confirm the Java 17 or 21 runtime and the database you will run on, using the CIB seven supported environments page, before you estimate staffing. The third is the support model: CIB seven's community edition is free and open source, while the paid Community+, LTS and Enterprise editions add security patches and hotfixes. Ask CIB which edition matches your regulatory and uptime needs, and ask how patch timing is committed in writing.
Which option fits which situation
This table matches common situations to the option that usually fits better, with the reason tied to CIB seven's documented features and licensing. Read each row as a starting point, then confirm the specific points against your own requirements and the CIB seven documentation.
| Situation | Better fit | Reason |
|---|---|---|
| Business analysts own day-to-day process changes | Bizagi | Bizagi's modeling and forms tools are built for analysts. CIB seven is a code-first engine, so changes to models usually pass through developers, and its built-in task list and monitoring do not replace a low-code modeler. |
| Regulated team needing on-premises or air-gapped runs | CIB seven | Bizagi now sells only its cloud PaaS, while CIB seven is Apache-2.0 licensed and runs inside your own Java and database stack. Confirm that your air-gapped build process can pull the required dependencies. |
| Team with strong Java developers | CIB seven | The engine runs in the Java Virtual Machine and supports Spring Boot, Quarkus, Docker and Kubernetes setups. Developers can version models, scripts and tests in Git alongside application code. |
| Process-heavy work with complex forms and a custom data model | Bizagi | Bizagi provides form design and data modeling in its platform. With CIB seven, forms, data model and user-facing screens must be built and maintained by your team, which is the largest rebuild effort in a migration. |
| Need for a usable task list and process monitoring without extra tools | CIB seven | From version 2.0, CIB seven ships its own user interface for task lists, process monitoring and user and rights management, independent of the Camunda Tasklist, Cockpit and Admin modules. Confirm the screens meet your user workflows before you commit. |
| Organization wants a paid support tier with security patches | CIB seven | The FAQ describes paid Community+, LTS and Enterprise editions with security patches and hotfixes, and recommends LTS for high-volume or regulated environments. Ask CIB for the support terms and duration of each edition in writing. |
| Existing Camunda 7 workloads that must keep running | CIB seven | CIB seven is a Camunda 7 compatible fork with a migration script for Maven artifacts and imports. Objects already stored in the database, such as script tasks referencing org.camunda classes, need manual review. |
| Team that expects a fully managed SaaS service | Bizagi | Bizagi's current model is cloud PaaS, so the vendor operates the platform. CIB seven is self-hosted, and your team or a partner must handle hosting, upgrades, backups and patching. |
How the choice changes by team type
Business-led teams model processes, own the queues and expect a working task interface on day one. CIB seven ships its own user interface for task lists, process monitoring and user and rights management, so these teams no longer depend on the Camunda Tasklist, Cockpit or Admin modules to see work. What they give up is Bizagi's visual modeler and its form designer, which assume a single vendor environment. The advantage matters most when developers can build screens and the team accepts BPMN in a standard modeler rather than a drag-and-drop tool.
- Task inbox: Work items, assignments and due dates are visible in CIB seven's own list without a separate portal build.
- Process monitoring: Running instances and stuck tokens can be inspected by operations staff without engine access.
- Modeling: Processes are drawn in standard BPMN 2.0 tools, which means a new modeler skill set and a different review workflow.
- Forms: Bizagi's form and data model work must be rebuilt as application screens or external forms.
- Rights: User and role administration is handled inside the product, so confirm it matches your directory and approval rules.
Before committing, ask a pilot group to run one real process end to end in the CIB seven interface and report where they still need a developer.",
Integration teams treat the engine as a component inside services, queues and APIs. CIB seven's core is a native BPMN 2.0 process engine running inside the Java Virtual Machine, and it fits Spring Boot and Quarkus setups with Docker and Kubernetes packaging. Teams that already know Camunda 7 get a familiar API, and the migration path from Camunda 7 Community Edition is documented. What they keep from Bizagi is the business-facing layer, which now has to be built or assembled from other components. This advantage matters when the team already runs Java services and has the capacity to own deployment pipelines.
- Embedding: The engine can run inside an application or as a standalone service, so integration patterns stay in code.
- Namespace move: Imports change from org.camunda to org.cibseven, and the migration script updates Maven versions and artifacts.
- Stored objects: Script tasks and variables that reference org.camunda classes in the database are not renamed automatically, so inventory them first.
- Platform support: Check the supported Java, database and application server versions listed for your target release.
- Connectors: Bizagi's prebuilt connectors have no direct equivalent, so each integration needs a developer-owned adapter.
Confirm the exact Java and database versions in your environment against the supported environments page before choosing a release line.
Regulated teams need to show who changed a process, which edition runs in production and how security fixes arrive. CIB seven's FAQ describes a free Community edition and paid Community+, LTS and Enterprise editions, and it recommends the LTS edition for high-volume or regulated environments. Paid distributions receive security patches and hotfixes on a cadence of every four to eight weeks, with urgent fixes as needed. The FAQ gives no fixed support duration per edition, so that term must come from the vendor in writing. Bizagi's cloud subscription offered a managed operating model, which these teams have to replace with their own change control.
- Edition choice: The LTS edition is the one the FAQ names for regulated environments, so price it into the plan.
- Patch cadence: Security releases every four to eight weeks must fit your patch window and testing cycle.
- Support term: Ask for the written support period for each edition, since the public FAQ does not state one.
- Audit trail: Process versions and deployment history must be retained and reviewed, using your own logging and change tools.
- Hosting: Data stays in your infrastructure, but backups, access reviews and monitoring become your responsibility.
Ask DeployOpen or the vendor to confirm the edition, patch commitments and support term in writing before a regulated rollout is scoped.
Where your process data and engine run
Bizagi now runs as a cloud PaaS, so your process models, case data and engine execution sit inside Bizagi's hosted environment, while CIB seven runs wherever you deploy it: your own cloud account, a data center or an air-gapped network. That shift changes who operates the database, who patches the Java runtime and who can prove where records live. Before comparing features, write down which data classes (personal data, payment details, clinical or case records) pass through the process engine and which of them must never leave your boundary.
Identity and audit are the two controls most affected by the move. CIB seven ships its own user interface for task lists, process monitoring and user and rights management, so you decide how users authenticate and which directory or SSO provider feeds it. Confirm whether your identity provider can supply the group claims your roles depend on, and test how the engine's history tables and your application logs record who completed or reassigned a task. Backup is also yours to own: the database that holds running instances and history must be backed up and restore-tested on a schedule you set, and that duty sits with your team or your implementation partner, not with a vendor. Confirm the supported database engines listed for CIB seven 2.2 against your own standards before you choose one.
For compliance readiness, ask your assessor which controls they expect you to evidence for the engine and its database, then confirm that you can produce those records yourself. CIB seven does not carry a certification that transfers to your environment, so any assessment covers your deployment. Ask the assessor how they want access logs, change records and backup restore results retained, and confirm the retention period with your compliance lead. Decide early whether the engine runs in a network segment that also hosts Bizagi-exported data during the transition, because that period is when data is most spread out.
What makes up the cost of each option
Bizagi's cost is mostly a recurring subscription, while CIB seven's license cost depends on which edition you choose. The larger costs in a move are often the same either way: hosting, rebuilding forms and the data model, developer time and migration of running cases.
Bizagi subscription
Bizagi now sells its cloud PaaS, so the subscription is a recurring cost paid to Bizagi for the platform, hosting and its vendor support. Ask what the quote includes for environments, user licensing and any cloud usage limits, and whether renewal pricing can change. The main cost to model is that it recurs every term for as long as you stay on Bizagi. Confirm the exit terms before you plan a move, since data export and the timeline for ending the contract both affect when you can switch off.
CIB seven editions
The Community edition is free under Apache License 2.0, and the FAQ says it may be used free of charge in commercial software, at least for its core functions. Community+, LTS and Enterprise are paid, and they add security patches and hotfixes. The LTS edition is the FAQ's recommendation for high-volume or regulated environments, so price that tier, not the free one, if you need patch assurance. Ask CIB which edition covers your Java and database versions and what each one's support window is.
Hosting and operations
Self-hosting moves infrastructure, patching, backups, monitoring and database administration onto your team or a partner. Costs depend on the Java application server, the database engine and the number of environments you run for development, testing and production. The supported database and servlet container list is broad, so pick the combination your DBAs already run. Ask for a written split of who patches the engine and the operating system, and at what cadence.
Forms and data model rebuild
Bizagi bundles forms, the work portal and a data model in one tool. In CIB seven, the engine runs processes but forms, task interfaces and data structures are yours to design and build. CIB seven does ship its own task list, process monitoring and user management UI, which removes part of this work, but business-specific screens and the database schema still need developers. This is usually a one-time cost, though it grows with the number of processes and forms you carry over.
Developer time
A code-first engine expects Java developers to model, test and deploy processes, write delegates and maintain scripts. This is an ongoing cost tied to how often processes change, so teams that edit processes weekly will spend more than teams with stable workflows. Factor in the skills gap if your low-code users currently change processes themselves. Ask a partner to estimate effort for your specific process inventory, and insist the estimate covers testing and handover.
Migration of processes and cases
Migration is mostly one-time work: converting BPMN exports, re-adding attributes the export drops, moving running instances and running old and new processes side by side until open cases close. CIB seven's Camunda migration guide notes that objects already in the database, such as script tasks or variables referencing org.camunda classes, are not renamed automatically. Budget time for that review and for parallel running. Ask for a cutover plan that lists which cases finish in Bizagi and which move across.
What moving from Bizagi to CIB seven involves
The sequence turns an inventory of Bizagi processes into a running CIB seven estate, with each process either migrated, rebuilt or retired and with old and new work paths checked side by side before the Bizagi copy is switched off.
Inventory processes and decide what moves
Your process owners and architects list every Bizagi process, its volume, its integrations, its forms and its business rules, then mark each one as move, rebuild or retire. Bizagi's export covers the BPMN 2.0 diagram, but it does not carry the forms, data model or rules, so those must be documented by hand. The step is done when each process has a recorded decision and a named owner.
Export diagrams as BPMN 2.0 XML
Engineers export the selected diagrams from Bizagi as BPMN 2.0 XML and store them in version control alongside the inventory. They then open each file in a BPMN modeler to confirm that tasks, gateways, sequence flows and pools survived the export. Bizagi-specific extended attributes may be lost, so the team records what must be re-added. The step is done when every selected diagram loads and matches its Bizagi original.
Rebuild forms and the data model
Because CIB seven is a process engine rather than a low-code suite, the forms, user interface and data model must be built again by your developers, using the engine's task list or your own front ends. Process variables are mapped to the data your applications store. Business rules that lived in Bizagi are moved into DMN decision tables or service code. The step is done when each migrated process can be started, completed and reported on without Bizagi.
Update Java and Maven artifacts with OpenRewrite
Developers apply the OpenRewrite-based migration script that CIB seven provides, which updates Maven versions, artifact names and Java imports from org.camunda to org.cibseven. Projects on older Camunda baselines must first move to the matching baseline named in the migration guide. The Liquibase changelog path is also updated. The step is done when the project builds and its unit tests pass against the CIB seven engine.
Handle org.camunda references stored in the database
The migration guide warns that objects already in the database, such as script tasks and variables that reference org.camunda classes, are not renamed automatically. Engineers search stored definitions and variables for these references, rewrite them, and decide whether the namespace compatibility properties are needed, since they are disabled by default. The step is done when a test instance of each process runs end to end on a database copy.
Run old and new processes in parallel
The Bizagi and CIB seven versions run side by side for a defined set of cases, with new work routed to CIB seven and in-flight Bizagi cases allowed to close in place. Operations staff compare outputs, task assignments and audit records from both paths. The step is done when the parallel results match the agreed acceptance criteria and open Bizagi cases have a closing plan.
Retire Bizagi processes and archive records
Once in-flight Bizagi cases are closed or transferred, the team switches the remaining processes to CIB seven, disables the Bizagi versions, and archives the exported diagrams, the inventory and the migration decisions as records. Your compliance team confirms what retention rules apply to the archived Bizagi data. The step is done when no active work runs in Bizagi and the archive has been reviewed by its owners.
Questions buyers ask before switching from Bizagi to CIB seven
Can a non-developer operate CIB seven day to day?
No, not for building processes. CIB seven is a code-first BPMN 2.0 engine that runs inside a Java application, so process models are deployed through Java and Maven tooling and business logic is written by developers. Its built-in user interface covers task lists, process monitoring and user and rights management, which lets business users work tasks and operators watch running instances, but it does not replace Bizagi's visual modeling. Plan for developers who own the models and for analysts who read them in the Modeler or a BPMN editor. The FAQ lists Spring Boot, Quarkus, Docker and Kubernetes setups, so your team also needs the skills to run those.
How much effort do forms and the data model take to rebuild?
Usually the largest share of the work. Bizagi's forms, business rules and data model live in its own tooling, and an engine export of BPMN 2.0 XML does not carry them. Each form has to be rebuilt in the front end you choose, each rule in code or a decision model, and each entity in a database schema that your application owns. The effort scales with the number of forms, the number of rules and how much data validation sits inside Bizagi today. Before quoting, inventory every form field, rule and data entity per process, and mark which ones users actually depend on.
What does the client team need to provide for this work?
Named owners for each process, access to the Bizagi exports and a team that can run Java services. Process owners confirm the business rules and exception paths, developers build forms and integrations, and a database or platform engineer provisions the database and hosting. CIB seven's supported environments list Java 17 and 21 with several databases, including PostgreSQL 15 to 18, so the platform team must choose and operate one of those stacks. Ask the implementation partner to write down which of these roles it covers and which it expects from you.
Can we run the migration in-house instead of hiring a partner?
Yes, if you have Java engineers who already maintain BPMN-based systems and the time to rebuild forms and data. The engine migration itself is supported by a documented path: CIB seven provides an OpenRewrite-based script that updates Maven versions, artifact names and imports, and its guide notes that projects on older Camunda versions must first move to the matching Camunda baseline. The harder part is the objects the script does not rename, such as script tasks and variables that reference org.camunda classes, which need manual review. An in-house team is most likely to succeed with a small pilot process before moving the full portfolio.
What drives the cost of this switch up or down?
The main drivers are the number of processes, forms and business rules, the depth of custom integrations, the database and hosting choice, and whether you buy a paid edition. Costs fall into one-time items (analysis, rebuild, testing, cutover) and recurring items (hosting, database licences if any, paid support, and the engineers who maintain the models). Ask any quote to split these, to name who is paid for each item, and to state which Java and database versions it assumes. Fixed-scope engagements are agreed in writing before work starts, which makes scope changes visible in the quote.
How do the paid LTS editions differ from Community?
The Community edition is free and open source under Apache License 2.0, while the paid Community+, LTS and Enterprise editions add security patches and hotfixes. CIB seven's FAQ recommends the LTS edition for high-volume or regulated environments and says patches for paid distributions arrive every 4 to 8 weeks, with urgent fixes released as needed. The FAQ gives no fixed support duration per edition, so ask the vendor for the support window of the specific LTS line you will run. Also confirm which Enterprise features are included, since the FAQ says Enterprise offers all Camunda 7 Enterprise features starting with version 2.1.2.
How does the Camunda 7 base affect support timing?
It ties your support timeline to the Camunda 7 lineage. Camunda ended community releases with 7.24, scheduled for October 14, 2025, and archived the community repository on November 4, 2025. CIB seven's backend for version 2.1 is based on Camunda 7.24.0, and CIB has provided support and maintenance for the Camunda 7 Community Edition since October 2025. Your security patch cadence therefore depends on CIB seven's own release and patch policy, not on Camunda. Check the current CIB seven version against the release tags before you commit, and document a plan for future upgrades.
Official CIB seven sources to read first
Before you shortlist CIB seven, read the primary sources yourself. Three questions matter most for a Bizagi replacement: which edition you would run in production, which CIB seven version and Camunda 7 baseline it tracks, and what license governs the code you will ship. The CIB seven FAQ answers the first and third: it describes a free Community edition and paid Community+, LTS and Enterprise editions, and it recommends the LTS edition for high-volume or regulated environments. Write down which edition your compliance and support requirements point to, then ask the vendor to confirm in writing what that edition includes, how long it is supported, and how patches are delivered.
Next, check versions and migration mechanics against the CIB seven manual's Camunda migration guide. It states which Camunda 7 baseline each CIB seven line is built on and warns that projects on older Camunda versions must first move to the matching baseline. It also lists the Java package and Liquibase path changes and the objects, such as script tasks and variables referencing org.camunda classes, that the OpenRewrite script will not rename. Your rebuild plan should include a search of stored definitions and scripts for those references, since the database will not be corrected automatically.
Finally, confirm the runtime stack against the supported environments page, which lists the Java versions, database engines and application servers that the current release supports, and against the CIB seven GitHub repository for the license file and release history. Pin your target to a specific tagged release rather than a branch, and have your architects verify that your database version, application server and JDK all appear in the matrix. Treat any version not listed there as unsupported until the vendor says otherwise.
How DeployOpen helps evaluate and implement CIB seven
This sequence takes an organization from a scoped evaluation of CIB seven to a documented, hardened and supported deployment inside its own infrastructure. Each step ends with a written output the client can check before the next one starts.
Agree the written scope and quote
DeployOpen reviews your current Bizagi processes, data sources, user groups and hosting constraints, then writes a fixed scope that lists deliverables, responsibilities and the timeline agreed with you. A quote follows from that written scope, so the cost reflects the work you approve rather than an estimate. The step closes when both parties have signed the scope document and the open questions about your environment are recorded.
Confirm fit against CIB seven requirements
The team checks CIB seven's supported Java, database and application server combinations against your standard platforms, and confirms whether the Community edition or a paid LTS edition matches your regulatory and patching requirements. It also maps which Bizagi capabilities you use, such as forms, business rules and the work portal, to what the engine and its built-in task list provide. The output is a written fit assessment that names every gap, including what your developers must build.
Plan the Camunda 7 compatibility and migration path
Where processes come from an existing Camunda 7 codebase, the team plans the baseline update and the namespace migration from org.camunda to org.cibseven. Where processes come from Bizagi, the plan covers how exported BPMN is reviewed, what extended attributes must be re-added, and how stored references to old class names are found and fixed, since the vendor guide notes these are not renamed automatically. The output is a migration design that lists each process, its owner and its cutover approach.
Rebuild forms, data model and task interfaces
Bizagi forms, business rules and the data model are not carried over by a BPMN export, so DeployOpen rebuilds them with your team in the target stack. This covers the task forms, variables, database tables and the access rules that the built-in user and rights management must reflect. The step closes when each rebuilt form has been tested against the process path it supports and the data model has been reviewed by your data owners.
Install, integrate and harden the platform
DeployOpen installs CIB seven in your own cloud accounts, data centers or air-gapped network, using the deployment model your team selects, such as Spring Boot, Quarkus, Docker or Kubernetes. It connects the engine to your identity provider, database, logging and monitoring, then applies hardening that your security team reviews against its own baseline. The output is a configured environment with a documented configuration baseline and a record of every change from defaults.
Set up backup, upgrades and runbooks
The team configures database backup and restore, tests a restore to confirm it works, and writes runbooks for routine operations and incident response. It also sets a patch process that follows the release cadence of the edition you chose, so security patches and hotfixes are applied on a known schedule. The step ends when a restore has been demonstrated and the upgrade procedure has been rehearsed in a non-production environment.
Prepare compliance evidence and run parallel cutover
DeployOpen documents controls, configurations and operational evidence in a form your compliance team and external auditors can use. It does not issue audit reports or certifications; independent auditors and certification bodies do that work. Old Bizagi and new CIB seven processes then run side by side until open cases close and the team signs off the cutover. The output is an evidence pack and a signed cutover record.
Hand over, document and support
DeployOpen hands over the architecture, configuration records, process inventory and training material to your operations team, and walks through them with the people who will maintain the system. Ongoing support, upgrades and continuous testing are available as retainers, which you can agree separately from the initial scope. The step closes with a documented handover that your team has accepted in writing.
