Which fits your BPM estate: IBM Business Automation Workflow or Operaton
IBM Business Automation Workflow fits teams that need a vendor-backed authoring environment and support contract, and Operaton fits teams that can own the engine, its integration and its upgrades. The decision usually arrives with a Cloud Pak for Business Automation renewal, a lifecycle date that forces an upgrade, or a Camunda 7 estate that needs an open engine after Camunda 7 Community Edition reached end of life. IBM's product bundles the modeling, UI and process application tooling that business analysts use day to day, so it suits an existing IBM estate with WebSphere or OpenShift skills and staff who expect a single vendor to answer for the whole stack. Confirm with IBM which runtime and Cloud Pak versions your contract covers before comparing anything else.
Operaton fits teams that already work in standard Java and want BPMN and DMN execution embedded in an application or run as a service through its REST API. It is an Apache-2.0 engine born from the Camunda 7 codebase, and its repository states a fully compatible REST API, database schema and deployable BPMN and DMN models, which lowers the cost of moving existing Camunda 7 process definitions. Its Operaton FAQ describes a community-maintained project with no single company in control and with governance still forming. Operaton has no commercial editions, so professional support comes from independent providers, and you should ask each one to commit to specific response terms in writing.
The decision turns on three questions. First, does your team need a vendor-backed UI, authoring tools and a single support path, or can it build its own user interfaces and accept that support is contracted separately? Second, can your release process absorb half-yearly feature releases with monthly patches and no traditional LTS line, given that each version is supported for 6 months until the next one ships? Third, how much engineering capacity do you have to operate the engine, test upgrades and maintain custom code? If the answers point to the IBM stack, the next step is a lifecycle review. If they point to Operaton, plan a pilot on your own database and Java runtime before committing.
Which option fits which scenario
This table maps common buyer situations to the option that usually fits best, with the condition under which each choice holds. Read each row against your own estate: the right answer depends on whether you are already committed to IBM, how much Camunda 7 code you run, and what in-house skills you can staff.
| Scenario | Better fit | Why |
|---|---|---|
| Existing IBM Cloud Pak estate with BAW apps and coaches | Stay on IBM for now, plan the exit | Operaton is an engine, so coaches, toolkits and the IBM authoring tools do not carry over. Choose Operaton only if you are rebuilding the UI and process logic anyway. |
| Camunda 7 code that must keep running | Operaton | Operaton 2.1 is API-compatible with Camunda 7 CE 7.24 and keeps database schema version 7.24, so existing Java code and BPMN models usually need fewer changes than a move to Camunda 8. |
| Embedded engine inside a Java application | Operaton or Flowable | Both run embedded in a Spring Boot or Jakarta EE application. Operaton suits teams already using Camunda 7 APIs; Flowable suits teams that also need CMMN case work. |
| Business users need a bundled modeling and UI suite | IBM BAW or a commercial vendor | Operaton ships an engine with no commercial editions or bundled authoring UI. Pick it only if you will build or buy the modeler, forms and task UI separately. |
| Data residency in air-gapped networks | Operaton | The engine runs from official Docker images or Helm charts on your own cluster, with no vendor connection required. Confirm the image and dependency mirroring process with your security team before committing. |
| Limited in-house Java skills | IBM BAW or a supported Operaton partner engagement | Operaton is a Java library and server with no single company in control. Without Java staff, budget for an independent provider to support upgrades and custom code, and confirm that support in writing. |
Where process data and runtime live under each option
IBM Business Automation Workflow runs as part of IBM Cloud Pak for Business Automation, either on the traditional WebSphere-based runtime or on container runtimes deployed on OpenShift or another Kubernetes platform. The licensed product, the application server layer and the cluster under it are usually managed by different teams, and each layer has its own patch and upgrade cycle. Your architects should map which layer your estate uses today before comparing it with a self-run engine.
- Runtime packaging: Confirm whether your estate runs the traditional WebSphere runtime or the container runtime, since the two carry different operational responsibilities.
- Platform layer: Identify who operates the OpenShift or Kubernetes cluster, the database tier and the storage that sit under the product.
- Support boundary: Record which components IBM supports directly and which your own team or a third party maintains.
- Upgrade path: Note which Cloud Pak and WebSphere versions are in use, since each upgrade touches several layers at once.
- Deployment specifics: Confirm topology, data placement and regional options with IBM in writing, because these depend on your contract and configuration.
Ask IBM to document where each runtime component and its database schemas sit in your specific configuration before relying on any of these details in a design.
Operaton is an Apache-2.0 BPMN 2.0 engine that you deploy yourself. It can run embedded in a Java application, as a standalone service with a REST API, or as distributions for Tomcat and WildFly, and it ships a Quarkus extension, Spring Boot integration and official Docker images and Helm charts for Kubernetes. Operaton runs wherever your infrastructure runs, whether that is a cloud account, a data center or an air-gapped network, so the location of runtime and data is a decision your team makes.
- Chosen runtime: Select the embedded, Spring Boot, Quarkus, Tomcat, WildFly or Kubernetes deployment that matches your application architecture.
- Database placement: Operaton supports H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2, so instance and history tables live in the database you choose and operate.
- Minimum database versions: The 2.1 release notes set PostgreSQL 14, MariaDB 10.11 and MySQL 8.4 as minimums, with Oracle 21, SQL Server 2022 and DB2 support unchanged.
- Runtime requirement: Version 2.1 requires Java 17 and is tested on Java 17, 21 and 25.
- Backup scope: Process state, history and deployed models are all in your database and file stores, so backup and restore plans must cover them together.
Confirm the exact database and Java versions for your target release against the official release notes before you size infrastructure.
Process instance state, variables, history and deployed definitions are the data that matters most for audits and for regulated retention rules. With a self-run engine, that data sits in a relational database you select, so residency, encryption and retention are configured in your own environment. With IBM, the location of runtime and process data depends on how the product is deployed and which databases it uses, which is a question for IBM and for your deployment design.
- Instance state: Running instances and their variables are stored in the engine's database schema, so the database tier defines where that data lives.
- History retention: Operaton's history tables and their cleanup settings control how long completed-instance data stays available, and these need an explicit retention decision.
- Model artifacts: BPMN and DMN files are deployed to the engine, and their version history should be kept in your own source control.
- Attachments and documents: Documents referenced by a process should be stored in your content system, not inside process variables, so the engine holds only references.
- Residency controls: Encryption at rest, backup locations and replica regions follow from the infrastructure you choose for Operaton.
Ask IBM for a written description of where process and history data is stored in your configuration, and map the equivalent answer for Operaton to your own database and backup design.
Identity decides who can start, claim and administer process work. Self-run engines integrate with the identity provider your organization already operates, through the servlet container, the Spring or Quarkus security layer, or a gateway in front of the REST API. Authentication and group membership therefore depend on the components you configure, not on a built-in directory bundled with the engine.
- Single sign-on: Operaton's web applications and REST API can be protected by the identity provider and protocols your platform team chooses, which should be tested with real user groups.
- Service accounts: Machine clients that call the REST API need their own credentials, scoped permissions and rotation rules.
- Group mapping: Map directory groups to process roles such as starters, task assignees and administrators, and keep that mapping under change control.
- Authorization model: Review the engine's authorization settings and confirm they match your separation-of-duties requirements.
- IBM integration: Confirm with IBM how its runtime connects to your directory and which identity integrations your contract covers.
Confirm the identity integration design with your security team and test it against a copy of your directory before go-live.
Auditors need evidence that process controls operate as designed: access reviews, change records, logs of administrative actions and retention settings. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the audit reports and certifications. The evidence you can produce depends on how the engine, its database and your logging pipeline are configured, so this area needs planning before an assessment begins.
- Change evidence: Deployment history for BPMN and DMN models should trace each version to an approved change.
- Access evidence: Logs of user and service account activity should be retained in a central store that your operations team controls.
- Retention evidence: Documented history retention periods and the jobs that enforce them should match your records policy.
- Backup evidence: Restore tests with recorded results show that process data can be recovered.
- Control mapping: Map each control to a framework your auditor uses, such as an ISO/IEC 27001 Annex A control or a SOC 2 criterion, and confirm the scope with that auditor.
Ask your auditor which evidence they will sample and whether IBM's documentation or your own records will serve as the source for each item.
What each option costs to run, by component
Licensing is only one line in the cost of running either option. The components below show who gets paid for what, which costs are one-time and which recur, and what to request in a quote before comparing the two sides.
IBM licensing and product fees
IBM Business Automation Workflow is a commercial product, so the license is a recurring cost that usually renews on a term basis, sold as part of Cloud Pak for Business Automation or as a separate entitlement. Ask the vendor which metric applies to your environment (for example, users, processing units or cores), whether support and upgrades are included, and how the price changes at renewal. Keep the one-time setup cost apart from the annual subscription so the renewal math is visible.
WebSphere or OpenShift platform beneath it
The product runs on a platform that carries its own cost: WebSphere runtime licenses for the traditional estate, or OpenShift subscriptions and cluster capacity for the containerized Cloud Pak deployment. Each platform layer has its own renewal and its own administrators. Before comparing, ask IBM for a bill of materials that lists every middleware and platform entitlement the product requires, so none of them surface later as an unplanned line item.
Operaton software and support
Operaton is Apache-2.0 licensed, has no commercial editions and no open-core model, so the software itself carries no license fee. The cost moves to professional support, which is available from multiple independent service providers and is priced by each provider. Request a written scope covering response times, hours, upgrade assistance and which Operaton versions are covered, since the project itself publishes no LTS line to anchor a support contract to.
Infrastructure and database
Operaton runs as a Java process on servers, containers or Kubernetes with official Docker images and Helm charts, so compute and storage are the main infrastructure costs. The database is a separate recurring line: the engine supports PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2, with minimum versions of PostgreSQL 14, MariaDB 10.11 and MySQL 8.4 in the 2.1 release. Commercial databases such as Oracle or SQL Server add license cost, while PostgreSQL usually shifts the cost to operations and backup.
Upgrade effort every six months
Operaton ships feature releases in April and October with monthly patch releases, and each version is supported for six months until the next one ships. That cadence is the recurring cost to plan for: each upgrade needs regression testing of your BPMN and DMN models, custom Java code and database changes. Compare this with IBM's lifecycle, where upgrades are scheduled by the vendor and bundled into the subscription. Budget the testing and change-control effort explicitly, either in-house or through a retainer.
Java, middleware and internal staffing
Operaton requires Java 17 and is tested on Java 17, 21 and 25, so someone must own JVM patching, application servers or Spring Boot and Quarkus builds, monitoring and on-call. This is the largest recurring cost for most teams and it does not appear on any vendor invoice. Estimate it as roles and hours: platform engineers, a process owner for models and at least one developer who can maintain custom Java delegates. Ask whether your current IBM operations staff can move to these tasks without new hires.
How Operaton's release cadence and support model change planning
Operaton changes the planning question from "which long-term branch do we pin?" to "which release do we move to next, and when?" Operaton ships half-yearly feature releases in April and October, with monthly patch releases in between. Each major or minor version is supported for six months, until the next one ships, and there is no traditional LTS line. The current line illustrates the rhythm: v2.1.0 was published on April 24, 2026, and the latest stable patch, v2.1.5, on September 18, 2026. Before committing, confirm the current support window and release calendar on the Operaton FAQ, since the cadence is stated there and in the releases page.
IBM Business Automation Workflow sits on the other side of that trade-off. IBM supports its product under its own lifecycle and contract, and the upgrade calendar is set by IBM and your entitlement, not by a community release train. Neither model is wrong for an enterprise. A bank or public body with quarterly change boards and a formal vendor escalation path may prefer a predictable vendor lifecycle, while a team with a strong platform function may accept a faster cycle in exchange for control over when it moves. Ask IBM to confirm, in writing, the support end dates for your exact release and fix pack, and compare them with your own change calendar.
Operaton's governance is still forming. Its FAQ says no single company controls the project, and there are plans to establish a non-profit organization to manage key decisions. Support comes from several independent providers, and the repository states there is no open-core model and no commercial edition. Practically, this means you should contract support before you need it, confirm which providers cover your database and Java versions, and set an upgrade policy that assumes a patch or minor upgrade every six months. Budget the upgrade test cycle as a recurring cost, not a one-off project.
How a move from IBM Business Automation Workflow to Operaton unfolds
The sequence turns a set of IBM process applications into Operaton-hosted BPMN and DMN models running on your own infrastructure, with in-flight work drained and the WebSphere or Cloud Pak estate retired. Each step ends with an output you can check before the next one starts.
Inventory process applications, toolkits and rules
Your team lists every process application, toolkit, business rule set, decision table, coach and form in the IBM environment, along with the services each one calls and the data stores it reads. The client owns this inventory because only the internal process owners know which applications are still in use and which are retired. A partner can help structure the inventory and flag IBM-specific dependencies. The step is done when every asset has an owner, a status (keep, redesign or retire) and a list of external integrations.
Classify models as keep or redesign
Each BPMN process and DMN decision is reviewed against Operaton's supported standards, BPMN 2.0 and DMN 1.3, and the team decides which models can be deployed unchanged and which need redesign because they depend on IBM-only constructs or proprietary service types. Models that originated in Camunda 7 may be candidates for the migrate-from-camunda recipe, but this applies only where the source is Camunda 7, not IBM Business Automation Workflow. The client owns these decisions. A partner can run the review workshops. The output is a classified model list that the business has signed off.
Map IBM-specific features to custom code or other UIs
IBM coaches, toolkit services and Process Designer features have no direct equivalent in Operaton, so each one is mapped to a replacement: a custom web front end, a form engine, a Java service task or an existing system of record. This mapping is usually the largest effort item in the project and is driven by how many coaches and custom services the estate contains. The client decides which user journeys matter and who will maintain the new interfaces. A partner can build or integrate these components under a written scope. The step is complete when every user-facing feature has a named replacement and an agreed owner.
Plan draining of in-flight instances
Running IBM process instances are not moved automatically to Operaton, so the team decides for each process whether to let active instances finish on IBM, to restart them in Operaton, or to migrate them with a custom procedure. The plan records which processes are long-running, which data must be carried across, and the cut-over date for new instance creation. The client must own the business decision on each in-flight case. The output is a written draining plan approved by the process owners and the operations team.
Build and test on Java 17 with the target database
The migrated models and custom code are deployed to a test environment running Operaton 2.1 on Java 17, backed by the database your organization chose from the supported list, such as PostgreSQL 14 or later, MariaDB 10.11 or later, or MySQL 8.4 or later. Testing covers process execution, DMN decisions, REST API calls, timers and integrations, and compares outcomes with IBM for representative cases. Confirm the Java and database versions against the Operaton release notes before you start. The step is done when test results are signed off and the environment matches the planned production configuration.
Deploy to production and drain the old runtime
Operaton is deployed to your infrastructure, using official Docker images or Helm charts if you run Kubernetes, or a standard Java application server if you do not. New process instances are created in Operaton from the agreed cut-over point, and IBM instances are monitored until the drain plan says they can close. Your operations team owns deployment, monitoring and backups, and a partner can provide support under a retainer. The output is a running production system with a documented runbook.
Retire the WebSphere or Cloud Pak estate
Once the last IBM instance has finished or been migrated and the audit records are archived under your retention policy, the WebSphere or Cloud Pak for Business Automation components are decommissioned, licenses are ended with IBM, and infrastructure is removed. The client must confirm with its auditors and compliance team which records must be kept and where. The step closes when the decommissioning checklist is complete and the configuration, models and documentation are stored in the organization's own repositories.
Questions buyers ask before choosing Operaton over IBM Business Automation Workflow
How much does a move from IBM Business Automation Workflow to Operaton cost?
Cost depends on the number of process applications, the custom Java code and integrations to rewrite, and the work to rebuild IBM's coaches and UI. Operaton itself is Apache-2.0 licensed with no commercial editions, so the license line disappears, but you still pay for infrastructure, the platform team, migration engineering, testing and any paid support from an independent provider. Ask IBM for the renewal and Cloud Pak cost you would stop paying, then ask Operaton providers for a fixed-scope quote based on an inventory of your process models and integrations.
How long does a migration take, and what changes the timeline?
The timeline is driven mainly by the number of running instances, the number of BPMN and DMN models to convert, and how much of your logic lives in custom Java or IBM-specific toolkits. Instances that are still in flight need a draining or migration plan, so a large backlog extends the schedule more than a large model count. Operaton publishes an OpenRewrite recipe for Camunda 7 code, which helps only if your IBM estate already uses Camunda 7 APIs, so confirm that with your provider before estimating. Agree a written scope and milestones before work starts.
What does our team need to run Operaton after the move?
Your team needs Java skills, familiarity with the BPMN 2.0, DMN 1.3 and CMMN 1.1 standards it supports, and operations skills for the database and container platform. Operaton 2.1 requires Java 17 and is tested on Java 17, 21 and 25, and it runs on PostgreSQL 14 or later, MariaDB 10.11 or later, or MySQL 8.4 or later, among other databases. Users of IBM's low-code authoring tools will need to learn how to build their own task UI, which is usually the largest skills gap.
Can we migrate without outside help?
A capable internal team can migrate a small estate alone, especially if it already runs Java services and has good test coverage. Larger estates with many toolkits, coaches and in-flight instances benefit from an implementation partner who can plan the cutover and test it. Whatever you choose, confirm which skills you already have, and write down which parts of the migration you will do yourself and which you will buy as fixed-scope work.
How does support work when Operaton has no LTS line?
Operaton ships feature releases in April and October with monthly patch releases, and each version is supported for six months until the next one ships. There is no traditional long-term support line, so you must plan regular upgrades within that cycle. Professional support and consulting come from multiple independent service providers rather than one vendor, so compare their response commitments in writing. Ask any provider how they handle patches, testing of new releases and rollback.
Does Operaton keep Camunda 7 REST API and database compatibility?
Yes, according to the Operaton repository, Operaton provides a fully compatible REST API, database schema and deployable BPMN and DMN models for Camunda 7 projects. Operaton 2.1 is feature complete and API-compatible with Camunda 7 CE 7.24 and keeps database schema version 7.24. Compatibility still needs testing against your own clients, custom listeners and plugins, because a working deployment does not prove every integration behaves the same way.
What happens if Operaton's community governance changes?
Operaton is maintained by an open-source community with no single company in control, and its FAQ says governance is still forming, with plans for a non-profit organization to manage key decisions. That lowers vendor lock-in because the Apache-2.0 code stays available, but it also means priorities are set by contributors. Ask your providers which maintainers they track, how they would fork or patch the code if development stalled, and what your exit plan looks like.
How DeployOpen helps evaluate, implement and migrate to Operaton
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For IBM Business Automation Workflow vs Operaton, that means starting from your process inventory and the Operaton release line you need, then building and handing over a platform your own team can run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which IBM process applications and decision models move to Operaton and which stay on IBM.
- Scope covers the database choice from the supported list, Java runtime, Docker or Helm deployment and REST API consumers.
How we build
- We deploy Operaton in your infrastructure using the official Docker images or Helm charts, matched to your target release.
- BPMN and DMN models are redeployed and tested against the REST API calls your systems make today.
- Custom Java delegates and listeners are reviewed for dependencies on Camunda 7 packages and moved to the org.operaton namespace.
How we hand over
- Handover includes runbooks for deployment, upgrades, database backup and restore, and monthly patch application.
- You receive documentation of the architecture, configuration, models and test results agreed in the scope.
- Your team is trained on operating the half-yearly release cycle, which has no LTS line, so upgrade planning is part of the handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, priced from the written scope.
- Support can cover tracking each Operaton release and planning upgrades before a six-month support window closes.
- DeployOpen prepares systems, controls and evidence for compliance assessments; independent auditors issue any audit reports.
