If you run traditional IBM Business Automation Workflow, you've felt the nudge. Every renewal conversation, every roadmap deck, every support notice points the same way: Cloud Pak for Business Automation. The nudge is real, and so are the deadlines behind it. The question isn't whether you'll engage with CP4BA — it's whether you'll do it on IBM's schedule or on yours.
The push: the support clock is not subtle
Look at the lifecycle dates for traditional BAW and the pattern is unambiguous:
Traditional BAW — the doors that have closed
Notice what's not being announced: a long, comfortable future for the traditional runtime. IBM's stated recommendation is to move to the current CP4BA releases. An estate on an out-of-support LTSR isn't saving money — it's accumulating unpriced risk in the layer that runs your business.
What CP4BA actually changes — and what it doesn't
The engines you know are all there: workflow, decisions, content, capture. What changes is everything around them. CP4BA runs containerized on OpenShift, managed by operators, updated on a cadence. Installation, scaling, patching and monitoring all work differently — mostly better, once your operations team crosses the learning curve.
The catch nobody puts on the first slide: artifact compatibility is not 1:1. IBM documents the differences between the traditional and container runtimes for a reason — some patterns that worked on-prem need rework in containers. Which is why the worst possible plan is the most tempting one.
The mistake: treating it as an infrastructure lift
"It's the same BAW, just in containers — lift it over" is how CP4BA programs end up stalled at 60%. A platform migration is the one moment you get to ask, per process: does this still earn its place? We've written before about wrap vs rebuild verdicts and about letting runtime data pick them — a CP4BA migration is exactly where that discipline pays. Migrating a dead process to a new platform costs the same as migrating a living one; only one of them is worth it.
A sane path, in four moves
- Assess first. Inventory the estate, score it on runtime evidence, and give every process a verdict: migrate as-is, rework for the container runtime, or retire. The retire list funds the rest.
- POC cheaply. IBM's Workflow Process Service — the lightweight, PostgreSQL-backed variant of containerized BAW — lets you validate your artifacts against the container runtime before you build production-scale OpenShift infrastructure. Use it. Theory and practice diverge exactly here.
- Migrate in waves. Same discipline as any estate move: waves sized to teach, parallel run where volume justifies it, automated regression as the cutover evidence. Big-bang platform migrations fail for the same reasons integration ones do.
- Operationalize the cadence. Continuous delivery means upgrades every year or two forever. Build the pipeline and the muscle once, during the migration — not as a surprise at the first update package.
The pull: agents land on the new platform
The support clock is the stick; here's the carrot. The current CP4BA releases are where IBM is wiring in the agentic capabilities — AI agent integration in the platform itself, and a documented path between CP4BA and watsonx Orchestrate. The modernization runway we keep describing — processes as governed tools, agents on the edges, determinism at the core — assumes a platform that's current. An estate parked on traditional BAW doesn't just carry support risk; it's parked outside the room where the agentic era is happening.
On your terms
CP4BA migration done reactively is an infrastructure project with a deadline. Done deliberately, it's the cheapest estate cleanup you'll ever get approved — the support clock provides the budget conversation, and the assessment makes sure you only carry forward what earns it. We run that assessment, we've crossed the container learning curve, and we know where the traditional-to-container gaps bite. Start with the verdict list, not the licence order.