The enterprise BPM category that IBM, Oracle, TIBCO and Pega dominated for two decades has split in two. The "BPMN modelled, audited, governed" use case shifted to Camunda 8 — cloud-native, BPMN 2.0, modular. The "long-running distributed workflow in code" use case grew into a new category around Temporal and Orkes Conductor. Camunda's analyst mindshare fell from 21.5% to 9.9% YoY (PeerSpot Jan 2026) while IBM BPM dropped from 7.3% to 4.1% — the whole category is contracting at the BPM-suite framing and growing under the orchestration framing. Top 5 modern platforms below, with migration patterns and SA enterprise context.
From the mid-2000s through the mid-2010s, the BPM Suite category was a single thing: a heavyweight server (often Java EE) that ran BPMN process models authored in a vendor-specific modeller, with built-in human-task forms, an admin console, and tight bindings to a vendor's ESB and rules engine. IBM BPM (formerly Lombardi Teamworks), Oracle BPM Suite, TIBCO ActiveMatrix BPM, Software AG webMethods BPMS, and Pega were the global incumbents. Six-figure USD licensing was normal; year-long implementations were typical.
By 2026, that single category has cleanly split into two:
The two halves serve different buyers. BPMN-modelled orchestration fits the buyer who needs auditable business processes, human-task approvals, and compliance reporting (banks, insurers, government, BPO). Workflow-as-code fits the buyer who is composing microservices into long-running flows with strict reliability semantics (e-commerce checkout, billing, identity, distributed jobs). A third half — data orchestration — has its own well-established category (Apache Airflow, Prefect, Dagster) but is rarely called "BPM."
Three structural pressures push the same way:
Cost. A typical IBM BPM or Pega deployment runs into seven figures USD over five years across licences, infrastructure, and partner-led implementation. Camunda 8 Self-Managed plus a small platform team often comes in at 30–50% TCO; Temporal Cloud (managed) bills per-action and scales naturally with use.
Cloud-native deployment. The legacy stacks were built around dedicated J2EE servers and proprietary middleware. Modern platforms ship as containers, deploy with Helm to any Kubernetes cluster, and integrate with the cloud-native observability stack (OpenTelemetry, Prometheus, Grafana) by default.
Developer experience. Process models in modern platforms live in git, get reviewed in PRs, are tested in CI, and deploy through standard CD pipelines. The legacy "deploy via the admin console, hope it works" model lost developer mindshare a decade ago and is still losing buyer mindshare.
Every credible process orchestrator — legacy or modern — is some implementation of these eight capabilities. The differences between platforms are how each capability is realised, how it scales, and how it composes with the rest of the stack.
BPMN 2.0 (Camunda, Flowable) or code (Temporal, Conductor, Argo). The notation is the buyer interface; the engine is the runtime.
Process state survives crashes, restarts, infrastructure failures. The defining technical claim of the category. Persistence in Postgres / Cassandra / dedicated stores (Zeebe).
External workers poll for tasks (Camunda 8, Temporal, Conductor) or the engine invokes connectors directly. Workers in any language; connectors for SaaS APIs.
Long-running processes outlive deployments. Versioning isolates running instances; migration policies handle in-flight upgrades. Often the hardest production concern.
Approval queues, forms, role assignment, escalations. First-class in BPMN platforms; second-class in workflow-as-code platforms.
Business rules in DMN 1.3 tables that business analysts can author. Camunda and Flowable ship this natively; Temporal / Conductor leave rules to host code.
Per-instance state, audit trail, SLA breach alerts, throughput dashboards. Camunda Operate / Optimize, Temporal UI, Conductor UI.
Kafka, NATS, RabbitMQ, AWS SQS / EventBridge integration as first-class. Modern orchestrators are event-native; legacy ones bolt this on.
Business Process Model and Notation 2.0 is the OMG-standardised visual notation for process models. Camunda, Flowable, IBM BPM, Activiti, Bonita, and many others implement BPMN to some degree. The practical implication: a BPMN model authored in one vendor's modeller is portable to another vendor's engine — though "portable" hides real friction, especially when IBM BPM exports drop diagram metadata (a documented Camunda migration gotcha). The DMN 1.3 companion standard does the same for decision tables. Together, BPMN + DMN are the reason migration from IBM BPM to Camunda is feasible at all.
The five below cover the realistic modern process-orchestration market for enterprise workloads. Two BPMN-modelled options (Camunda 8, Flowable) for IBM BPM / Oracle / TIBCO replacement scope; two workflow-as-code options (Temporal, Orkes Conductor) for distributed-system orchestration; one Kubernetes-native option (Argo Workflows) for compute-heavy / data-pipeline-adjacent workloads.
The most credible direct replacement for IBM BPM, Oracle BPM Suite, and TIBCO ActiveMatrix at the enterprise tier. Cloud-native architecture (Zeebe is a stream processor over a partitioned log, deployed as Kubernetes pods), BPMN 2.0 + DMN 1.3 standards-compliant, REST and gRPC APIs, Modeler is a separate desktop / web app, task workers in any language. Self-Managed edition is source-available (a commercial licence is required for production); SaaS edition (Camunda Cloud) is managed by Camunda. The Camunda migration consulting team ships tools specifically for IBM BPM, IBM Blueworks Live, and TIBCO process imports.
Pick when: the replacement target is IBM BPM / Oracle / TIBCO / Pega and the buyer needs BPMN modelling, human-task workflow, DMN decision tables, and an audit-grade engine. The default for SA bank / insurer migrations off the legacy stacks.
The dominant workflow-as-code platform. Forked from Uber's internal Cadence by the original authors in 2019; now powers durable-execution workflows at Uber, Snap, Coinbase, Stripe, and Datadog. Workflows are written in the host language (Go, Java, TypeScript, Python, .NET, PHP, Ruby) and the Temporal engine guarantees durable execution — state survives crashes, retries are automatic, versioning is built-in, signals and queries are first-class. No visual modeller; the workflow IS the code. Temporal Cloud is the managed offering (per-action billing); Temporal Self-Hosted is Apache 2.0 OSS.
Pick when: the workload is distributed-system orchestration (microservices composing into long-running flows) and the team has the engineering depth to operate it. Not the right pick for BPMN-modelled business processes or human-task heavy approval chains.
Netflix originated Conductor in 2016 to orchestrate microservices that drive the Netflix studio and platform. Orkes (founded by the original Conductor authors) commercialised it as a managed enterprise platform in 2022. Workflows can be defined as code, in a UI editor, or in JSON configuration — the cross-edit between formats is a distinguishing feature. Strong observability dashboards; pragmatic developer-meets-ops positioning. Apache 2.0 OSS for the open source; Orkes commercial for the managed enterprise tier.
Pick when: the team wants flexibility across code and visual workflow definition, or already has Netflix Conductor in production and wants the managed upgrade path.
The most credible fully-open-source BPMN engine. Fork of Activiti (which itself is the open-source lineage of jBPM); Flowable forked in 2016 and has been more active since. Implements BPMN 2.0, DMN 1.3, and CMMN 1.1 (Case Management Model and Notation) under a single engine. Apache 2.0 across the board for the core engine; Flowable Work / Engage / Inspect are the commercial add-ons for human-task UI and admin consoles. Smaller community than Camunda but a real production option for teams that need an open-source BPMN engine without commercial licence dependencies.
Pick when: the requirement is BPMN + DMN + CMMN under permissive open-source licensing and the team is willing to integrate / build the human-task UI themselves (or pay for Flowable's commercial add-ons).
Kubernetes-native workflow engine. Every workflow step is a container, every workflow is a Kubernetes CRD. Designed for compute-heavy parallel workloads (ML training, scientific computing, data pipelines) where the orchestrator should treat the cluster as the runtime. CNCF graduated project (mature governance), Apache 2.0 OSS. Not a BPMN engine and not a workflow-as-code engine in the Temporal sense — workflows are YAML or code-generated YAML. Pairs with Argo Events for trigger-based execution and Argo CD for continuous deployment.
Pick when: workloads are container-shaped, compute-heavy, and already on Kubernetes — especially ML pipelines, batch jobs, and infrastructure orchestration. Not the right pick for business-process orchestration with human tasks.
n8n — low-code workflow automation for citizen developers and integration use cases; fair-code (sustainable-use) licence; not enterprise BPM but excellent for SaaS integrations and operational glue. Apache Airflow — the dominant data-orchestration platform; Python DAGs; not designed for transactional business processes but the right answer for ETL / ELT scheduling. Prefect and Dagster — modern data-orchestration alternatives to Airflow with cleaner developer experience. Windmill — newer fair-code automation platform combining workflows + scripts + UI. AWS Step Functions — managed state-machine orchestration for AWS-native shops; vendor-bound but operationally clean. Activiti and Bonita — older BPMN engines, declining; usually replaced by Camunda or Flowable in new deployments.
| Concern | IBM BPM | Pega Platform | Camunda 8 | Temporal |
|---|---|---|---|---|
| Licence cost | USD per-PVU + per-CPU; seven-figure floor | USD per-user + per-server; seven-figure floor | Camunda commercial licence (~mid five figures for entry) or SaaS per-process; Self-Managed source-available | Temporal Cloud per-action; Self-Hosted Apache 2.0 free |
| BPMN modelling | Native; proprietary extensions to BPMN | Proprietary case-flow (not BPMN); some BPMN import | Native; BPMN 2.0 reference implementation | None (workflow is code) |
| DMN decisions | Vendor-specific rules engine | Pega Rules | Native DMN 1.3 | Decisions in host language |
| Cloud-native deploy | Java EE; containerisable but not k8s-native | Java EE; vendor-managed cloud or self-hosted | Kubernetes-native; Helm charts | Kubernetes-native; Helm charts |
| Human task workflow | Native + portal | Native + portal (the strongest in the field) | Native via Tasklist + Forms | External (UI must be built; SDK provides primitives) |
| Mindshare trajectory (Jan 2026) | 4.1% (was 7.3%) | Steady in low-code BPM | 9.9% (was 21.5%) — whole category contracting | Rising in workflow-as-code |
| Vendor lock-in | High — proprietary process artefacts, IBM ecosystem assumptions | High — Pega-specific everything | Low — BPMN exports portable, OSS Self-Managed available | Low — workflow code is yours, OSS is Apache 2.0 |
An important nuance for migration planning. Camunda 7 is the older Java embedded engine (released 2013, last 7.x line received support through 2025+ with extended LTS). Camunda 8 is the newer cloud-native rewrite around Zeebe (released 2022). They are different products with the same brand — different engine, different operations model, different commercial terms. New deployments default to Camunda 8 unless there's a specific reason to extend Camunda 7. Migration from Camunda 7 → Camunda 8 is a real project (engine differences, deployment model, connector pattern), not a version upgrade.
Three credible migration shapes from IBM BPM / Oracle / TIBCO / Pega to a modern orchestrator. None is fast; all are doable. Camunda Consulting has shipped the most-used migration toolchain — tools that parse IBM BPM, Blueworks Live, and TIBCO exports and emit BPMN-2.0-compliant files, but in practice 30–50% of the model is hand-rewriting because the legacy stacks embed vendor-specific extensions (BPEL, custom Java service tasks, IBM-only event subprocess shapes) that don't map cleanly.
1. Strangler (most common for IBM BPM / Oracle / TIBCO). New processes are authored natively in Camunda 8 (or Temporal) from day one. Existing processes stay on the legacy engine and migrate process-by-process, usually keyed off business-event boundaries (a new product launch, a regulatory change that requires re-implementation anyway, a SLA renewal that justifies the project). Both engines coexist for the migration window (often 2–5 years). The legacy licence cost drops only when an entire process suite is decommissioned, so cohort sizing matters for cost realisation. Camunda's "Replace Legacy BPMS" playbook documents this pattern in depth.
2. BPMN-import + adapt (for in-scope greenfield rewrites). Use the Camunda Migration Toolkit to parse the legacy export, regenerate as Camunda-compatible BPMN, and accept that the regenerated model is a starting point for rebuild, not a drop-in replacement. The structure transfers; the task implementations, forms, and engine-specific extensions need to be re-authored. Useful when the legacy model has long since lost its original authors and the documentation is the BPMN itself.
3. Greenfield (for transactional / event-driven workflows). The workflow is rewritten in Temporal or Orkes Conductor as code, without any attempt to preserve the legacy BPMN model. Appropriate when the legacy process is technical (service composition, distributed transactions) rather than business-process-shaped, and the team is willing to take the workflow-as-code stance.
IBM BPM exports are BPMN-compliant except they omit the diagram metadata. Open them in Camunda Modeler and you get a "No Diagram To Display" error — the process definition is there, but the visual layout was stripped. Camunda's migration tools work around this by regenerating layout from the structure. Plan accordingly: the migration is faster than "re-implement from scratch," but slower than "import and ship."
Banking + insurance are the SA install base. Most of the country's major banks and insurers ran (or still run) IBM BPM, Pega, or Oracle BPM Suite as the BPMN engine behind onboarding, claims processing, loan origination, and KYC. These deployments are typically 10–15 years old. As with the ECM equivalent, the move to modern orchestrators is strangler-pattern almost everywhere — new lines of business launch on Camunda 8 (or Camunda Cloud); legacy workflows stay on the incumbent until SLA renewal or regulatory change forces re-implementation.
Parastatals + government. Several SA parastatals run Pega or IBM BPM, often via large SI partners (Accenture, Deloitte, EOH-line successors, BCX). The B-BBEE preferential-procurement framework affects partner selection; the choice of modern orchestrator follows the partner's competency. Camunda has a small but growing SA partner network; Temporal is largely self-implemented in SA today.
POPIA-friendly residency. Self-hosted Camunda 8 Self-Managed or Temporal Self-Hosted on SA-resident infrastructure (Hetzner Cape Town, Teraco, on-prem datacentre) keeps process state and audit trail in country. Camunda SaaS (Camunda Cloud) is hosted in vendor-selected regions; verify residency in writing before signing. Temporal Cloud has multi-region support; SA hosting requires either AWS af-south-1 (limited Temporal Cloud presence) or self-managed Temporal on a local cluster.
Cost in ZAR. Legacy BPM Suite licences are USD-denominated and a meaningful chunk of TCO. A R200k/month IBM BPM annual support cost (per typical SA enterprise contract) becomes R210k/month at R18.50→R19.50 FX. Camunda commercial licences are also USD but materially smaller; self-managed Camunda or Temporal removes the licence-FX exposure entirely (only infrastructure and labour remain). For SA businesses managing rand-driven operating costs, the modern stack is an FX hedge in addition to a feature decision.
Skills availability. Java BPMN engineers (Camunda, Flowable) are findable in SA at acceptable rates. Temporal expertise is rarer and more expensive; greenfield Temporal projects typically rely on remote / offshore engineering for the first 6–12 months while local skills are built. Factor into platform selection.