Is IBM Business Automation Workflow end of support forcing your next move?
If your process platform runs on Cloud Pak for Business Automation 23.0.x or 24.0.x, you need a decision before its support window closes. The choice is between a supported upgrade to a newer IBM release and a replacement, and the right answer depends on three things: the lifecycle dates that apply to your exact version, the inventory of processes, cases and decisions you actually run, and the team that will operate the result. Confirm the exact lifecycle and extended support dates for your version on IBM's own product lifecycle pages and against your contract, because this page does not restate them and those dates decide how much time you have.
Start with the inventory. Count the process applications, toolkits, case solutions and decision services in production, and note which ones use IBM-specific authoring tools, coaches, or custom Java that depends on the Cloud Pak runtime. A heavily customized estate makes any move expensive, whichever direction you take. Then ask who will run the platform after the decision. A supported upgrade keeps your team on a familiar IBM stack with IBM support. A move to an open-source engine such as Flowable or Operaton shifts responsibility for patching, hardening, backup and integration to you or to an independent provider, and that shift only works if the people and runbooks exist before cutover.
Open-source engines are a good fit for some estates and a poor fit for others. They suit teams that mainly run BPMN processes, CMMN cases and DMN decisions, have Java skills, and can build their own user interfaces. They are a weaker fit where business users depend on a bundled modeling and case UI, or where the organization needs a single vendor accountable for the whole stack. Write down which group you are in before you ask for quotes, so that each option is priced against the same scope.
What the end-of-support decision requires from your estate
Before you pick an upgrade path or a successor engine, you need written dates, a full inventory, and a clear view of the runtime under it. These five requirements feed the same decision, so gaps in one will distort the cost and timeline of the others.
Confirmed lifecycle dates from IBM
Get the end of support date for each Cloud Pak for Business Automation version you run, plus any extended support terms, in writing from IBM. Confirm which dates apply to the exact release on each cluster, because 23.0.x and 24.0.x environments may not share the same end dates. Ask whether security fixes stop on the same day as general support, and whether extended support is priced separately. Use these dates as the fixed point for your project plan.
Inventory of process apps and toolkits
List every process application, toolkit, shared library, coach and business object definition, with its owner, version and last change date. Mark which items are in production, which are in test, and which nobody has opened in a year. Retired items cost nothing to leave behind, while active items each need a redrawn BPMN model or a rebuilt interface in any successor. This list becomes the baseline for effort estimates from any vendor or partner.
Case solutions and in-flight instances
Count running process instances, active case instances, pending human tasks, timers and scheduled jobs for each application. Record which cases use stages, milestones or document folders, since CMMN work does not map one to one onto BPMN. Decide per application whether to let instances finish on the old runtime or migrate their state. Instances with long timers or decade-long case files often drive the migration schedule more than the code does.
Runtime footprint across WebSphere and OpenShift
Document where each environment runs: traditional WebSphere, the Liberty-based container runtime, or OpenShift under the Cloud Pak. Record the Java versions, database servers, message components, content stores and load balancers that each environment depends on. Note which parts are shared with other products, because those components may need their own upgrade plan. Your hosting team should confirm this map before anyone prices a move.
Skills and support model for the successor
Decide who will model, build, patch and operate the successor, and whether the work sits with in-house staff, a commercial vendor or independent providers. Check the release cadence and support windows of any engine you consider, because a platform that ships every six months needs a steady patch routine. Confirm that your team can run the framework version the engine requires. Ask each candidate for its support terms in writing before you commit.
How the Cloud Pak lifecycle dates shape the IBM upgrade
End of support is the date after which the vendor stops shipping fixes for a version, and that date, not the feature list, sets the deadline for a production process platform. Without security patches, a version that still runs your approved processes becomes a risk your auditors and security team will ask you to close. Extended support is a separate, usually paid, arrangement that some vendors offer for a limited period after the standard date. Whether IBM offers it for the Cloud Pak for Business Automation 23.0.x or 24.0.x lines, and on what terms, is not something this page can confirm. Ask IBM in writing for the exact end dates in your contract, what fixes continue after them, and what that coverage costs per year.
Vendor precedents show the pattern without describing IBM's terms. Camunda extended the end of life of Camunda 7 Enterprise Edition from April 2027 to April 9, 2030, with fee-based extended support from April 2030 through April 2032, according to Camunda's announcement. Appian's Appian on Kubernetes FAQ states that 25.3 is the last self-managed version that runs outside containers, and that 25.3 or earlier environments cannot upgrade to 25.4 or later without moving to Appian on Kubernetes or Appian Cloud. Pega describes 36 months of support per version. The lesson for your plan: the supported upgrade path may require a platform change (for example, moving from WebSphere to containers), not only a version bump.
The gap between your last supported version and the next supported one drives the project. List each process application, its toolkits, the database and the WebSphere or OpenShift layer under it, then map which of these an upgrade touches. A version bump that also forces a runtime change, a database upgrade or a rebuild of custom code is a migration in disguise, and its effort should be scoped as one. If the gap is long, or the upgrade path depends on components you already plan to retire, moving to an open-source engine such as Flowable or Operaton may be the better use of the same budget. Decide that with a written estimate for both paths, not with the renewal date alone.
Which upgrade or replacement path fits each constraint
This table compares the upgrade-in-place path on IBM with open-source engines and one licensed Camunda option. Read each row against your main constraint, such as keeping a proprietary runtime, staying on Java, or keeping an open license. The main takeaway is that open-source engines replace the runtime, but your team then owns the UI, identity and operations.
| Path | How it meets the constraint | What the team needs | Main trade-off |
|---|---|---|---|
| Upgrade IBM Business Automation Workflow in place | Keeps current process apps, toolkits and coaches running on the IBM platform with no re-platforming. | IBM entitlement, an IBM support path and a confirmed target version. Confirm lifecycle dates with IBM. | Keeps the proprietary runtime and its licensing, so the end-of-support question returns at the next cycle. |
| Flowable (Apache-2.0) | Covers BPMN, CMMN and DMN in Apache-2.0 engines with Java and REST APIs, so case and decision work can move too. | Java developers, a Spring, servlet or Java EE host, a database, identity integration and your own UI. | Engines only. Flowable 7 removed the UI applications and form engine, and 8.0.0 drops Spring Boot 3 support. Commercial editions add modeling tools. |
| Operaton (Apache-2.0) | Release notes list BPMN 2.0, DMN 1.3 and CMMN 1.1 compliance, with a REST API and schema matching Camunda 7 CE 7.24. | Java 17 or later, a plan for monthly patch releases, and the OpenRewrite recipe for any Camunda 7 code. | Half-yearly releases, six months of support per version, no LTS line, and governance still forming. |
| CIB seven (Apache-2.0) | Native BPMN 2.0 process engine running inside the JVM, suited to Java teams that want a standalone engine. | Java developers, your own application and UI, and a review of its release history and support providers. | Confirm DMN, CMMN and REST coverage, release cadence and support options against your processes before committing. |
| Camunda 8 Self-Managed (Enterprise license) | Supported BPMN and DMN orchestration on Kubernetes. Production use requires the Enterprise license since 8.6. | Kubernetes operations, an Enterprise license, and a plan to redraw IBM processes in BPMN. | Recurring license cost for production. Core components are source-available under the Camunda License v1. |
Which path fits your IBM estate today
If your Business Automation Workflow estate runs on the WebSphere-based traditional runtime, the first question is whether IBM still offers a supported move within its own stack. Confirm that with IBM for your exact version before you compare it with an open-source engine, because the answer changes the cost and timing of either path. An open-source move means the process engine runs in an application you operate, which changes who owns the server, patching and clustering.
- Simplest upgrade path: Ask IBM in writing which traditional runtime versions still receive support and whether a move to the container runtime is offered for your version.
- Most rebuild effort: Process apps that depend on WebSphere-specific services, proprietary components or custom Java code must be inventoried and rebuilt on a new runtime.
- Measure first: Count process apps, running instances, integrations and custom classes that reference WebSphere APIs or deployment descriptors.
- Engine options: Flowable and Operaton run on standard Java, so you choose a servlet container, Spring Boot or a standalone service, and you test that choice.
Before you pick a path, check the end-of-support date and any extended support terms for your version with IBM, and get them in writing.
If your estate already runs on the Liberty-based container runtime, the simplest route is usually to stay on the platform and move to the next version IBM supports. Your largest cost is then the upgrade itself, plus the Kubernetes or OpenShift platform beneath it. A replacement is a separate project that replaces the engine, the packaging and the operations model together, so it needs its own plan and test cycle.
- Simplest upgrade path: Confirm with IBM the supported upgrade route from your current container version and the platform versions it requires.
- Most rebuild effort: Moving to an open-source engine means rebuilding process models, custom code and the deployment pipeline, even though the containers themselves are familiar.
- Measure first: Record cluster capacity, database versions, Java versions in use and how many processes run at peak, since these drive both paths.
- Engine options: Operaton publishes official Docker images and Helm charts, and its 2.1 release requires Java 17 and is tested on Java 17, 21 and 25.
- Database checks: Confirm that your database versions meet the minimums of the engine you select, because older databases can block an upgrade on either path.
Schedule a test instance on your own cluster before you commit, and keep the IBM upgrade route open until that test passes.
If a large share of your work is case management, such as claims, onboarding or investigations where the sequence of work is not fixed in advance, the path choice depends on how much of that work relies on IBM's case capabilities. Confirm with IBM which case features your version supports and how they are packaged. Flowable provides a CMMN engine for case types, stages and milestones, but the case user interface, document handling and case data model are work you own in either path.
- Simplest upgrade path: Keep the case solutions on IBM if support confirms your version, and plan the upgrade around the case solutions first.
- Most rebuild effort: Rebuilding case types in CMMN, plus the case worker interface, is usually the largest effort because Flowable's open-source edition does not include a case UI.
- Measure first: Count case types, stages, milestones, documents attached per case and the screens case workers use daily.
- Document store: Decide where documents live before you design cases, since the content store is a separate system you must integrate and secure.
- Engine scope: Operaton's compatibility statement covers CMMN 1.1, but confirm the case features you need against that engine before you plan around it.
Write down the case types that generate most of your volume, and use them to size the pilot.
If your estate depends on custom coaches and a large number of user screens, the UI usually drives the effort more than the process engine does. Coaches built in IBM's tools do not move to a new engine on their own, so each screen needs a replacement decided by its users. Flowable's open-source edition removed its UI applications and form engine in version 7, so you should plan to build or buy a user interface and not assume one comes with the engine.
- Simplest upgrade path: If coaches are few and stable, staying on IBM's supported version is usually the lower-effort option, provided IBM confirms support for it.
- Most rebuild effort: Replacing dozens of coaches with your own front end, including validation, roles and accessibility checks, is usually the largest item in a replacement.
- Measure first: Count coaches, screens, user roles, validation rules and the integrations each screen calls.
- Identity: Flowable lets you replace identity management through its IdmIdentityService interface, so map your directory and roles before the UI design starts.
- Commercial add-ons: Flowable's commercial editions add low-code modeling and monitoring, which you should price against your own build effort.
Share the screen inventory with the business owners of each process before you estimate a replacement.
How to deploy Operaton or Flowable after IBM end of support
This sequence moves a Business Automation Workflow estate onto a self-hosted open-source engine in controlled phases, so each process is inventoried, rebuilt, tested and drained before the old runtime is retired. It produces a running engine in your infrastructure and a documented cutover record.
Freeze new process builds
The project lead and process owners stop starting new process apps, toolkits and case solutions on the IBM runtime, except for changes that fix defects or meet regulatory needs. Each exception is logged with an owner and a reason. The step is done when the change freeze is written down, communicated to business owners and enforced in the build and release calendar, so that the rebuild scope stops growing while the inventory is taken.
Inventory and classify process apps and cases
Architects and BPM developers list every process application, toolkit, business object, coach, human service, integration and case solution, with its owner, volume of running instances, integrations and data stores. Each item is classified by business criticality, regulatory exposure and rebuild effort. The output is a register that shows which items must move first, which can be retired and which need a decision from the business. Confirm with IBM which artifacts exported from your version can be read, since not all of them carry over.
Choose the engine and database
The platform team compares Flowable and Operaton against the inventory, using the BPMN, CMMN and DMN coverage each process set needs. Operaton is an API-compatible continuation of the Camunda 7 codebase and is a fit where teams already have Camunda 7 knowledge. Flowable provides CMMN case management and an event registry. On the database side, Flowable lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and Operaton lists PostgreSQL 14, MariaDB 10.11, MySQL 8.4, Oracle 21, SQL Server 2022 and DB2 as minimum or tested versions. Confirm current support in each vendor's documentation before you commit.
Deploy on Kubernetes or embed in Spring Boot
Platform engineers deploy the chosen engine either as official Docker images or Helm charts on your Kubernetes platform, or as embedded starters inside Spring Boot applications. Flowable provides Spring Boot starters for each engine and an actuator endpoint at /actuator/flowable. The async executor coordinates nodes through lock owners and lock expiration times stored in the database, so you must test cluster size, job executor thread pools and database connection limits under realistic timer and async load. The step is done when a multi-node test environment runs jobs without duplicates or stalls.
Build identity and access integration
Security and identity engineers connect the engine to your directory and single sign-on, mapping user groups to candidate groups and administrative roles. Flowable documents replacing its identity management by implementing the IdmIdentityService interface, with an LDAP reference implementation. Operaton's identity and authorization model should be confirmed against your access rules. The step is done when test users see only the tasks, instances and administrative functions their roles allow, and when access reviews can produce the mapping as evidence.
Run a pilot with representative processes
A small set of inventoried processes, chosen for variety in forms, timers, subprocesses and integrations, is rebuilt and run in a non-production environment with business testers. Each defect and each missing capability found is recorded against the register. The pilot closes when the rebuilt processes produce the same outcomes as the IBM versions on agreed test cases, and when the team has a runbook for deployment, backup, restore and upgrade. Note that the UI you build replaces IBM coaches, so front-end work belongs in this pilot.
Migrate or drain in-flight instances
For each process, the team chooses between migrating running instances, where the data model allows it, and draining them to completion on the IBM runtime while new work starts on the new engine. Drain plans state which instances complete on the old runtime, who approves the cutover and how orphaned tasks are reassigned. The step is done when instance counts on the old runtime reach zero for each retired process, and the migration log records every exception.
Retire the WebSphere or Cloud Pak estate
Once no process depends on the IBM runtime, operations removes the WebSphere or Cloud Pak components, deletes or archives databases under your retention policy, revokes service accounts and updates the configuration management and backup inventory. The step is done when the decommission record lists each component removed, its data disposition and the approver, and when the new engine's backup and restore tests have been completed and retained as evidence for your assessors.
Evidence auditors and regulators ask for during an end-of-support change
An end-of-support change touches the platform, the processes running on it and the people who can reach them. The artifacts below connect those three areas, so a reviewer can trace each running process back to a decision, a tested engine and a controlled identity setup. DeployOpen prepares these records, while independent auditors and certification bodies decide what any assessment or attestation means.
Dated lifecycle decision record
A signed record of why the estate moves to an upgraded IBM release or to an open-source engine, with the date, the options considered and the owner who approved the choice. Start it from the current support status of your Cloud Pak for Business Automation version, and confirm the dates with IBM rather than relying on internal memory. Auditors usually ask first for this record because every later artifact points back to it.
Supported-version matrix for the chosen engine
A table listing each component the new platform depends on, including the engine version, Java runtime, application server, database and operating system, with its vendor support window. For Operaton, confirm the supported versions in the release notes and the FAQ, since its releases follow a six-month support window with no LTS line. For Flowable, record which major version you pinned and why.
Process inventory with named owners
A register of every process application, case solution and decision model that runs today, with a business owner, a technical owner and the planned target for each item. Include in-flight instance counts and any custom code or integrations. This is the artifact that shows nothing was dropped during the change, and it is often the most time-consuming to build for an estate that has grown over several years.
Migration test and drain records
Test evidence for each migrated process: input data, expected outcomes, actual results and the sign-off by the business owner. Add drain records that show when old instances finished, were moved or were closed, and who approved the cutover. Keep failed tests and their fixes as well, because reviewers look for how defects were handled, not only for a clean result.
Backup and restore test results
A dated result from restoring the process database into a separate environment, showing that the restored data opens, the engine starts and running instances resume. Record the restore time you measured and the recovery point you achieved. Confirm the backup tooling for the database engine you choose, because a backup that has never been restored is not evidence that recovery works.
Access and identity configuration
Exports of the identity provider settings, role mappings, administrator accounts and group-to-task assignments, plus a record of the last access review. Flowable documents a way to replace its identity management service with your own implementation, so record which directory it reads from and who can change it. Auditors check that no shared or default accounts remain active after cutover.
What teams ask before replacing or upgrading IBM Business Automation Workflow
What drives the cost of an IBM upgrade compared with a rebuild on open source?
The biggest cost difference comes from which lines recur. An IBM upgrade keeps the Cloud Pak for Business Automation license and the WebSphere or OpenShift platform under it, so those costs continue after the project ends. A rebuild on Flowable or Operaton replaces that license with engine licenses that are free under Apache-2.0, but you still pay for servers, database, Java and Kubernetes operations, the rebuild itself, the UI you will write, and support. Ask any vendor or partner for a quote that separates one-time project effort from recurring license, platform and support fees, and ask what drives each line up or down, such as the number of process apps, case solutions, integrations and users.
How long does a replacement or upgrade project take?
No duration is given here because it depends on the size of your estate, including the number of process apps, toolkits, case solutions, integrations and in-flight work. Estimates made without an inventory are guesses. The reliable way to get a timeline is a written scope that lists the systems in scope, the deliverables, the environments and the acceptance criteria. DeployOpen works mainly on fixed scope, so scope, deliverables and timelines are agreed in writing before work starts. Ask IBM for the current end-of-support and extended support dates for your exact version, since those dates set how much room you have to plan.
What does the internal team need to contribute to the project?
The internal team owns the business knowledge and the decisions that an engine cannot make for you. Expect to name process owners who can confirm how each process should behave, subject matter experts for each case type and decision table, and a platform owner for the Java, database and Kubernetes or application server layer. You will also need a security reviewer for identity, secrets and logging, a test group that can run regression scenarios, and an approver for the cutover plan. Ask any implementation partner to list these roles in the written scope so you can assign people before the work starts.
Can our own team migrate without outside help?
A capable team can do it, but the answer depends on skills and capacity rather than on the software alone. Flowable provides Java and REST APIs, Spring Boot starters and embedding options, so a team with Java, BPMN and database experience can start with a pilot process. Operaton offers an OpenRewrite recipe, but that recipe targets Camunda 7 code, so it does not convert IBM artifacts. Most IBM estates include coaches, toolkits and custom services that need redesign, which is where outside expertise saves rework. Many teams use a short pilot to test their own capacity before deciding. DeployOpen offers implementation, testing and hardening under fixed scope, and ongoing support as retainers.
How are in-flight process instances handled during the cutover?
In-flight instances are the main cutover risk, and the approach should be chosen per process rather than applied to the whole estate. Common options are letting running instances finish on the old platform while new starts go to the new engine, or migrating selected instances with a tested mapping. Flowable's async executor stores lock owners and lock expiration times in the database, so expired locks are recovered and jobs are picked up by other nodes, which matters for timers and asynchronous work during and after the move. Ask IBM which instance state can be exported and confirm that any mapping is tested on copies of production data before you commit to a date.
Does Operaton or Flowable have an LTS release line?
Operaton has no traditional LTS line. According to the Operaton FAQ, it ships half-yearly feature releases in April and October with monthly patch releases, and each major or minor version is supported for six months until the next one ships. That means you need an upgrade plan at least twice a year to stay supported, which should be budgeted as recurring effort. Operaton 2.1 keeps the Camunda 7 CE 7.24 database schema and requires Java 17. For Flowable, the supplied information does not describe an LTS policy, so ask Flowable directly for its support lifecycle for the version you plan to run before you commit.
What happens to coaches and the user interface after the move?
Coaches and other IBM user interfaces do not carry over to an open-source engine, so you will need a front end for each task. Flowable 7.0.0 removed its UI applications, form engine and content engine, so the open-source edition gives you engines and REST APIs, not the screens. Flowable's commercial products, including Flowable Work, Engage, Orchestrate and Design, add low-code modeling and governance on the same engines. Operaton is focused on the engine and REST API, so its UI would also be your own build. Estimate the UI as a separate workstream, because it often costs more than the engine work for a process-heavy estate.
Who supports the platform after go-live?
Support comes from a mix of providers, and the source depends on the engine you choose. Operaton is maintained by an open-source community with no single company in control, and its repository describes professional support and consulting from multiple independent service providers. Its governance is still forming, with plans for a non-profit organization. Flowable offers its community forum for open-source users, while professional services and partners are offered separately, and its commercial editions are built on the same engines. DeployOpen provides ongoing support, upgrades and continuous testing as retainers, which you can set against a written scope. Confirm response expectations and who carries patching responsibility before go-live.
How DeployOpen plans an end-of-support migration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For IBM Business Automation Workflow end of support, we start by agreeing in writing what the upgrade or replacement covers, then build and hand over a working platform your team can run.
How we scope
- Inventory every process app, toolkit, case solution and integration that runs on the current Cloud Pak estate
- Confirm the lifecycle dates and extended support terms directly with IBM before choosing a path
- Compare the cost of the next IBM upgrade with the cost of a replacement, component by component
- Agree the scope, deliverables and timeline in writing before any work starts
How we build
- Redraw processes in BPMN and cases in CMMN on the chosen open-source engine, such as Flowable or Operaton
- Rebuild decision logic in DMN and replace coach-based user interfaces with the client's own front ends
- Run the engine on the client's Kubernetes, WebSphere or bare metal environment with database and async job configuration tested
- Test in-flight instances, timers and integrations before any cutover, and document results for assessors
How we hand over
- Deliver architecture, runbooks, backup and restore procedures and upgrade notes in the client's own documentation set
- Drain or migrate running instances according to an agreed cutover plan, with rollback steps written down
- Train the operations and development staff who will own the platform after handover
- Provide evidence for compliance assessments, while independent auditors and certification bodies issue any formal reports
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Track upstream release cycles so patches and version upgrades are planned rather than reactive
- Keep the platform current with security testing scoped to the client's application and infrastructure
- Review the retainer scope each year against the client's changing process portfolio
