Why the WebSphere runtime forces a decision on IBM BAW
The decision in front of you is whether to move your traditional WebSphere-based BAW estate to the Liberty-based container runtime, or to rebuild the processes on an open-source engine such as Flowable or Operaton running on standard Java. The constraint is the runtime itself. Process applications, custom services and integrations were built on an application server with its own configuration model, data sources, user registry bindings and deployment tooling, and each of those dependencies comes with the platform. Moving the runtime carries those dependencies forward in a new form, while rebuilding on a Java engine means deciding which of them still matter. Which path fits depends on what the estate actually contains, so start with an inventory before you form a preference.
Start the inventory with the artifacts that will not move unchanged. Process applications and their toolkits are the obvious items, but also check custom Java code that calls WebSphere-specific APIs, JNDI lookups, library versions bundled in the server, and any Coach views or REST integrations that point at hard-coded server addresses. Record each external connection, including databases, message queues, directory services and document stores, along with the credentials and certificates behind them. Then count the running instances and open tasks that must finish or be migrated. Confirm in writing with IBM which of these artifacts are supported on the target container runtime and at which release, because that answer determines whether the container move is a configuration project or a rebuild in disguise.
The second half of the decision is cost and exit risk. A container move keeps the IBM licensing, the Cloud Pak or OpenShift platform beneath it and the IBM support contract, so ask for a quote that separates each component and states which costs are one-time and which recur. A rebuild on Flowable or Operaton shifts the cost into engineering time, the database and container or VM hosting you run, and support, which can come from the vendor or from independent providers. Whichever path you choose, plan the cutover around in-flight instances and write down the rollback point before the first production move. Do not sign off the inventory until the team can name an owner for each external dependency.
What the runtime constraint requires from any target
Whichever path you choose, the target has to supply a Java runtime, a durable database, identity, job execution across nodes and a routine for backups and upgrades. These five cards list what each one must do for a WebSphere estate and what to verify before committing to a migration or a rebuild.
Java runtime and application container
Every candidate runs on the JVM, so the first decision is whether the engine runs embedded in your own application server or as a standalone service. Flowable can run embedded in Tomcat, Jetty, Spring or Java EE servers, or as a REST service, and Operaton ships Spring Boot, Quarkus, Tomcat and WildFly distributions. Confirm the Java version each target requires (Operaton 2.1 requires Java 17) and check that your custom Java code and WebSphere-specific APIs have a home on the new runtime.
Persistent database and transactions
Process state, timers, history and variables live in a relational database, so the database and its transaction behavior become part of the design. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and SQL Server, and Operaton adds MariaDB. Map every JTA or XA transaction and datasource your BAW components use on WebSphere, and confirm the minimum database versions and driver support with the vendor before you size the target.
Identity and access integration
BAW on WebSphere typically resolves users and groups through the application server's user registry, and that binding must be rebuilt. Flowable documents replacing its identity service by implementing the IdmIdentityService interface, with an LDAP implementation offered as a reference. Operaton relies on the same pattern from its Camunda 7 heritage. List every role used in task assignment and inbox routing, and confirm how each target maps those roles to your directory or SSO provider.
Timers and async jobs across nodes
Timers, boundary events and async continuations must fire exactly once when several nodes run. Flowable's async executor stores lock owners and lock expiration times in the database, so a node that fails holds its jobs only until the lock expires and another node picks them up. Test this under load with a node killed mid-job, and confirm the lock timeout and thread pool size you will run in production. Scheduled work tied to BAW on WebSphere must be inventoried before cutover.
Operations, etcd backups and upgrades
Containerized targets add a platform you must run: Kubernetes needs a highly available control plane, and Kubernetes documentation requires a backup plan for etcd using snapshot saves, with restores handled separately. Upgrade cadence is set by the project, so plan skew between control plane and nodes. Define who owns backups of the engine database and etcd, how restores are rehearsed, and which upgrade windows the business accepts before you choose a platform.
Containers or replacement: how the two paths differ
The container path keeps you on IBM's product model and moves the hosting layer from traditional WebSphere to the Liberty-based container runtime under Cloud Pak for Business Automation. Your process applications and the team's knowledge of the IBM toolchain carry over in principle, but whether IBM's tooling converts each artifact for your release must be confirmed with IBM before you plan the effort.
- Platform change: The runtime, deployment model and operations change, even though the process model looks familiar to the business.
- Carries over: Process applications and team knowledge of the IBM authoring tools, subject to IBM confirming the conversion path for your version.
- Does not necessarily carry over: WebSphere-specific server configuration, custom server extensions and scripts written for the traditional deployment model. Record each one during inventory.
- Team demands: Container, Kubernetes and OpenShift operations skills, plus Cloud Pak administration.
- Cost profile: IBM licensing and platform costs recur. Ask for a quote that separates one-time migration effort from annual subscription and infrastructure.
Ask IBM for a written list of unsupported artifacts for your release before you commit to a migration estimate.
Flowable provides Apache-2.0 Java engines for BPMN process execution, CMMN case management and DMN decision rules. The engines can be embedded in a Java SE application, a servlet container, a Spring application or a Java EE server, or they can run as a service through REST APIs. Flowable 8.0.0, released on February 27, 2026, requires Java 17 or later and moves to Spring Boot 4 and Spring Framework 7, with no backward compatibility for Spring Boot 3.
- What you rebuild: Each IBM process and case is redrawn in BPMN or CMMN, and decisions move to DMN. The standards give you a vendor-neutral model to rebuild from.
- Runtime choice: Pick the embedding model based on your architecture and team skills, because the engine itself is the same in each option.
- Team demands: Java and Spring development, a new user interface for task work and an identity integration. Flowable 7.0.0 removed the UI applications from the open-source distribution, so the UI is your build.
- Operations: The async executor coordinates nodes through lock owners and lock expiration times in the database. Plan the database platform and clustering up front.
- Commercial option: Flowable's commercial editions are built on the same engines and add low-code modeling and governance. Compare them against the open-source route in the quote.
Confirm your Java 17 and Spring Boot baseline with your platform team before you pick a Flowable version.
Operaton is an Apache-2.0 BPMN 2.0 engine forked from the Camunda 7 Community Edition codebase. Its 2.1 release is feature complete and API-compatible with Camunda 7 CE 7.24, keeps database schema version 7.24, requires Java 17 and is tested on Java 17, 21 and 25. If your team already runs BPMN models and Java services on a Camunda 7 style engine, this path keeps that shape most closely, but it still requires checking every model against your own inventory.
- Runtime fit: Operaton 2.1 is based on Spring Boot 4.0.6 and Spring Framework 7.0.7, and it ships Quarkus, Tomcat and WildFly distributions, official Docker images and Helm charts.
- Standards: The release notes list BPMN 2.0, DMN 1.3 and CMMN 1.1 compliance. Confirm each model you plan to reuse, because IBM-specific extensions do not map automatically.
- Migration tooling: The repository provides an OpenRewrite recipe for Camunda 7 code. It does not cover IBM artifacts, so IBM source assets need separate conversion.
- Governance and support: Operaton is community-maintained, has no commercial editions and has no single company in control. Professional support comes from several independent providers.
- Upgrade cadence: Feature releases arrive in April and October, patches monthly, and each version gets six months of support without an LTS line. Budget recurring upgrade work.
Check the Operaton 2.1 release notes against your database versions, which must meet the stated minimums.
Whichever path you choose, some IBM assets will not move as they are. The traditional runtime and the container runtime each depend on their own user interface components, adapters and configuration, so those items need an explicit decision. No artifact-level conversion mapping is established here, so treat each category below as a question to answer through inventory and with IBM.
- Coaches and user interface: IBM coach views and portal pages need rebuilding on either the container path or the open-source engines.
- Toolkit and designer assets: Proprietary toolkit libraries and designer-specific model artifacts must be checked case by case for each destination.
- Integration adapters: Connectors, messaging bindings and JNDI-based resources need equivalents, configured for the new runtime.
- Server and data source configuration: Application server descriptors, data source definitions and security settings change between the WebSphere and container environments.
- Running instances: Instances in flight need a draining or migration decision, separate from the code decision.
Build the inventory against IBM's list of supported artifacts for your release, and record each item as carried over, rebuilt or retired.
Which open-source engine fits which estate
This table compares Flowable, Operaton and CIB seven on how they run on standard Java, which databases and REST APIs they offer, how they are governed and how often they release. Read the gap row alongside the others, because every option requires rebuilding the WebSphere-specific UI and authoring layer. Flowable suits teams that want BPMN, CMMN and DMN in one engine family, while Operaton suits teams that want Camunda 7 API compatibility.
| Capability | Flowable | Operaton | CIB seven |
|---|---|---|---|
| Runtime on standard Java | Embeds as a JAR in Java SE, servlet containers such as Tomcat or Jetty, Spring and Java EE servers, or runs as a REST service | Integrates with Spring Boot, Quarkus and Jakarta EE, with Tomcat and WildFly distributions and official Docker images and Helm charts | Native BPMN 2.0 engine inside the JVM; confirm embedding, container and Spring options with the project |
| Java and framework baseline | Version 7 moved to Java 17, Spring Boot 3 and Jakarta EE; version 8.0.0 requires Spring Boot 4 and drops Spring Boot 3 | Version 2.1 requires Java 17, is tested on Java 17, 21 and 25, and targets Jakarta EE 11 and Spring Boot 4.0.6 | Confirm supported Java and framework versions in the current release notes before planning |
| Supported databases | H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server; MySQL below 5.6.4 lacks millisecond precision | H2, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server and DB2; minimums are PostgreSQL 14, MariaDB 10.11 and MySQL 8.4 | Confirm the database list and minimum versions with the project |
| REST API | Provides a REST application and REST starters for the engines | Fully compatible REST API with Camunda 7 CE, so existing client calls may carry over | Confirm REST availability and its compatibility with other engines |
| Modeling standards | BPMN, CMMN and DMN engines plus an event registry engine, all Apache-2.0 | BPMN 2.0, DMN 1.3 and CMMN 1.1 compliance listed in the 2.1 release notes | Native BPMN 2.0; confirm CMMN and DMN coverage before choosing |
| Governance and support | Apache-2.0 open source with a community forum; commercial editions on the same engines; professional services from Flowable and partners | Community-maintained with no single company in control; governance still forming, with a non-profit planned; no commercial editions; support from independent providers | Apache-2.0 licensed; confirm the maintainers, governance model and available support providers |
| Release cadence and lifecycle | Releases 7.1.0 (October 7, 2024), 7.2.0 (August 21, 2025) and 8.0.0 (February 27, 2026) | Half-yearly feature releases in April and October with monthly patches; each version supported six months; no LTS line | Confirm release cadence and support windows with the project |
| Gaps for a WebSphere estate | Open-source edition omits UI applications and the form and content engines, so coaches, forms and content must be rebuilt | Engine-only; no authoring tools or UI, so coaches and forms must be rebuilt, and six-month support windows require frequent upgrades | Confirm which UI, authoring and migration tooling exists before estimating rebuild effort |
How to deploy the chosen target under the constraint
This sequence takes a WebSphere-based BAW estate to a self-hosted engine on a highly available Kubernetes control plane, with secrets, access and backups in place before any process moves. Each step closes with a check you can verify before the next one starts.
Inventory BAW artifacts and runtime dependencies
The platform team and process owners list every process application, toolkit, service, coach, business object, external connection and scheduled job running on the WebSphere runtime. They also record the databases, LDAP or identity sources, message queues, file stores and certificates each one depends on. Confirm the inventory with the IBM documentation for your exact release, because artifact types differ between traditional and container runtimes. The step is done when every artifact has an owner, a target disposition (redraw, rebuild, retire or keep) and a list of the dependencies it needs at runtime.
Choose the engine and database
Decide between Flowable and Operaton based on which BPMN, CMMN and DMN features your inventory actually uses, whether you need CMMN case management, and how your team plans to handle version upgrades and support. Confirm the database you will run against from the engine's supported list, and check the minimum database versions in the engine's current release notes. Record the decision and the reasons in an architecture decision record. The step is done when the engine, version and database are approved and a non-production database instance is provisioned.
Stand up a highly available Kubernetes control plane
The infrastructure team builds the cluster with kubeadm using the stacked or external etcd topology described in the kubeadm high availability guide. Plan at least three control plane nodes behind a TCP load balancer that fronts kube-apiserver on port 6443. For etcd, use an odd number of members, and the Kubernetes documentation recommends five members in production. Schedule and test etcd snapshot backups with etcdctl snapshot save, and rehearse a restore with etcdutl before any workload lands. The step is done when a control plane node can fail during a test without losing API access and a restore from snapshot has been completed in a lab.
Configure secrets encryption and least-privilege RBAC
Kubernetes stores Secrets unencrypted in etcd by default, so the platform team enables encryption at rest for Secrets and restricts list and watch access with least-privilege RBAC roles. Decide whether database credentials and certificates come from an external store through the Secrets Store CSI Driver or from encrypted Secrets. Configure user authentication through OpenID Connect, client certificates or your existing identity provider, and apply the Pod Security Standards to the namespaces that hold the engine. The step is done when a test account without rights cannot read the engine's Secrets, and the encryption configuration has been verified against the cluster's etcd data.
Deploy the engine with async executor and identity integration
Deploy the chosen engine as a container image or Helm chart in its own namespace, pointing it at the database and pinning the version. Enable the async executor on each node, because Flowable's async executor coordinates nodes through lock owners and lock expiration times in the database, so expired locks are recovered by other nodes. Replace the default identity service with an LDAP or directory-backed implementation that matches your user and group model. The step is done when a test process with a timer and an asynchronous job completes on a multi-node deployment, and a stopped node's jobs are picked up by another node.
Run parallel verification
Rebuild a representative set of processes and decisions on the new engine, then run them alongside the WebSphere runtime with the same test data. Compare task assignments, decision outputs, timer behavior, and the audit trail or history records that your controls depend on. Involve process owners to sign off on outcomes, not only on technical results. Keep a log of each difference and its resolution. The step is done when the agreed test cases pass, every difference is either fixed or accepted in writing, and the operations team has run the backup and restore procedure against the engine's database.
Plan cutover and drain in-flight instances
Agree the cutover window with the business owners, then decide for each process whether running instances finish on WebSphere (drain) or move to the new engine. Stop new starts on the old runtime for the processes being moved, and confirm the count of open instances and tasks before and after. Keep the WebSphere environment and its database available for read access until the drained instances close and the retention requirements are met. The step is done when a written cutover runbook lists rollback steps, owners and the reconciliation checks, and the open instance count on the old runtime reaches zero or an agreed residual list.
Questions buyers ask before choosing a migration path
Is a Liberty container migration cheaper than rebuilding on Flowable or Operaton?
It depends on which costs each path removes and which it keeps. A container move preserves process models and most custom Java code, so the engineering effort is usually smaller, but you keep IBM licensing, the container platform beneath it and IBM support for as long as you run it. A rebuild removes the IBM license and the WebSphere estate, but adds work to redraw processes in BPMN, build a new user interface and test the new engine. Ask for both options costed against the same inventory. Separate one-time work (migration, testing, cutover) from recurring costs (licenses, platform hosting, support, upgrades). Each cost line should name who is paid for the work.
How long does the migration take, and what sets the duration?
Duration depends on your estate, and no sourced figure exists for it, so confirm it with IBM for the runtime change and with your own inventory for the rest. The main drivers are the number of process applications, toolkits and custom Java services, how many depend on IBM-specific components, the volume of in-flight instances that must finish or move, the number of integrations, and the testing your internal controls or regulators expect. Ask for a timeline broken down by each of these items, with dependencies between them shown, before you accept a single total.
What does our team need to supply for a migration project?
The project depends on people who know the estate as much as on the platform. Expect to supply named owners for each process application and integration, read and admin access to the existing WebSphere and authoring environments, database, certificate and identity details, and representative test data. Business owners must approve redrawn models and acceptance tests, and operations staff must agree on the cutover window and rollback steps. Teams often underestimate the time needed to find out which in-flight cases must complete on the old runtime and which can be moved.
Can our own team migrate from WebSphere without an outside partner?
Possibly, if your team already runs Java services, Kubernetes and a relational database in production. The container path needs skills in the platform, the runtime and the process models, and the open-source route also needs an engine, identity integration and a UI build. Kubernetes operations are a serious step: the kubeadm high availability guide describes a control plane of at least three nodes behind a TCP load balancer, and etcd needs a backup plan from day one. Assess honestly which of these skills you have, which you would hire, and which would stay with a partner.
Which IBM artifacts will not carry over, and how do we confirm the list?
Artifacts that depend on IBM-specific runtime services, proprietary UI components such as coaches, and IBM packaging will not run unchanged on an open engine, and some may not run unchanged on the container runtime either. Confirm the list against IBM's migration documentation for your exact version, then check it against your own inventory of process applications, toolkits and custom code. On the open-source side, check what your target version removes: Flowable 7.0.0 dropped its UI applications, form and content engines and async history, and Flowable 8.0.0 requires Spring Boot 4. Test each carried-over artifact in a non-production environment before you commit.
Who supports the platform after cutover, and what does that cost?
Support is the recurring line most often missed in comparisons. On the IBM path, support comes through your existing IBM agreement for the life of the product. On Flowable, the open-source edition has a community forum, while professional services and partners are offered separately and commercial editions add tooling. Operaton has no commercial editions and gets professional support from several independent providers, with feature releases in April and October, monthly patches, and each version supported for six months until the next ships. Ask each option for its support model, release cadence and who answers a production incident.
What does a fixed-scope DeployOpen engagement include for this migration?
A DeployOpen engagement is fixed-scope: scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. An illustrative scope could cover an inventory of process applications, toolkits and integrations, a recommendation between the container path and a rebuild, redrawn models, a platform build in your own cloud account or data center, hardening, backup and documentation, and cutover support. DeployOpen does not publish a price list. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
Evidence to keep for the migration
A migration off the WebSphere runtime creates evidence in several places at once: the artifacts you inventory, the tests you run against the data and the platform, and the version records that show what was running and when. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any attestation or certification.
Artifact inventory
Keep a dated list of every process application, toolkit, service, custom Java class, integration and business rule in the traditional runtime, with an owner and a disposition for each item. Mark which items are rebuilt as BPMN or DMN, which are rewritten as Java code and which are retired. The inventory is the baseline every other card is measured against. Check it against the running estate, not only the design repository, because undocumented customizations often appear only there.
Data migration test results
Record the outcome of each test run that moves in-flight instances, variables and history from the old runtime to the new engine. Keep row counts, sample instance comparisons and a list of instances that were drained rather than migrated. Include the database type and version used in each run, since Operaton 2.1 sets minimum versions for PostgreSQL, MariaDB and MySQL. Ask the target engine vendor which migration path they support for your source version.
Backup and restore tests
Keep records of restore exercises for the database layer and, if you run Kubernetes, the etcd cluster that stores cluster state. Kubernetes documentation says etcd needs a backup plan, uses etcdctl snapshot save for backups and etcdutl for restores. A backup that has never been restored in a test is not evidence that recovery works, so record the restore time, the data checked afterwards and the person who signed off.
Access control and secrets configuration
Export and keep the RBAC bindings, service account settings and the authentication method used for each user group, so you can show who can read or change workflow resources. Record whether Kubernetes Secrets are encrypted at rest, since they are stored unencrypted in etcd by default, and where database credentials are held. Keep this evidence as a dated export from the cluster, not as a description written after the fact.
Engine and platform version records
Keep a register of the version of every engine, Kubernetes control plane component, node runtime and database in use, with the date each was deployed and the date its support ends. Kubernetes maintains only the three most recent minor releases, and the skew policy limits how far kubelets may lag the API server. Operaton ships releases half-yearly with monthly patches and no LTS line, so its support window is short. Keep these records current so you can show what was supported at each point in time.
What to confirm with IBM and in your own environment
Before you compare a container migration with a rebuild, confirm three things with IBM and by inspecting your own estate: which WebSphere-specific artifacts and integrations your processes depend on, whether the Liberty-based container runtime supports each component you use, and whether your current licence terms cover running the container runtime at all. Start with an inventory. List every process application, toolkit, custom Java service, JAAS or security configuration, JDBC data source, messaging connection, and any scripts or deployment descriptors that reference WebSphere administration. Each item is a candidate for a gap that a container packaging may not carry over.
Next, ask IBM in writing which components in your current deployment are supported on the container runtime at your target version, and which are deprecated, changed in behavior or unavailable. Ask for the same answer for every integration you run, including authentication, document or content stores, and any custom widgets or embedded components. Do not rely on a general statement that a product family is containerized. Map each component to a supported version, then test it on a copy of your data. Record which answers came from IBM documentation and which came from a conversation, because that record will matter when your auditors or procurement team review the decision.
Finally, confirm the licence position before any project starts. Ask whether your entitlement covers the container runtime, what metric applies to it, whether moving to containers changes the metric or the cost basis, and whether the entitlement runs through a Cloud Pak subscription or a standalone agreement. Also confirm the support end dates for your current version, since a migration that ends after support lapses is a different decision from one that ends inside it. These answers, together with the artifact inventory, define the scope you would put in a written quote for either path, and they determine whether moving to an open-source engine on standard Java is the simpler option.
How DeployOpen approaches a WebSphere exit
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For an IBM BAW traditional WebSphere estate, we start by inventorying what runs today and agree the path in writing before any work begins, whether that is a move to the containerized runtime or a rebuild on a self-hosted engine.
How we scope
- Inventory every WebSphere-hosted process application, toolkit, service and integration that the migration or rebuild must cover
- Record which artifacts need manual rework, such as Coach-based user interfaces and proprietary extensions, before estimating deliverables
- Agree scope, deliverables and timelines in writing, with ongoing support available as a retainer once the work is handed over
How we build
- Stand up the target runtime in your own cloud accounts, data centers or air-gapped network, with Kubernetes or the Java platform you choose
- Redraw or convert process models and decision logic, then test them against recorded in-flight scenarios and integration endpoints
- Wire identity, database, secrets and backup components to your existing standards, and run security testing before cutover
How we hand over
- Deliver runbooks for deployment, upgrades, backup and restore, and etcd or database recovery where Kubernetes is involved
- Document configuration, custom code, test evidence and the controls and records your compliance assessors will ask for
- Walk your platform, development and operations teams through the running system so they can operate it without us
How we support
- Provide upgrades and patching for the target platform on a retainer that matches your release and change-control calendar
- Run continuous security testing of applications and APIs as the process estate changes after cutover
- Prepare evidence for compliance assessments, while independent auditors and certification bodies issue any audit report or certification
