On-premises TIBCO BusinessWorks applications accumulate operational cost. The engineers who built the integrations move on. Documentation drifts behind the flows that actually run. Keeping the platform available through peak loads takes continuous effort. And when an integration is business-critical, every security patch and version upgrade competes with an uptime requirement that leaves no easy maintenance window.
Cloud modernization is the standard answer, and for most enterprises it is the right one. Moving these applications off the on-premises footprint makes them more scalable, easier to secure, and cheaper to operate, without discarding the business logic they carry. The decision is rarely the hard part. The execution is.
Two failure modes dominate. Teams choose the wrong migration strategy, or they choose a reasonable one and run it in a way that surfaces unanticipated work, cost, and manual effort late in the project. Both trace to the same root: an ESB estate that no one can fully see into, moved as if every part of it were the same kind of thing.
The goal of migrating TIBCO BusinessWorks to a modern iPaaS is not to rewrite every integration. It is to stop running them in a black box.
That reframes the project. The value is not in converting BusinessWorks processes faster. It is in moving less of the estate, understanding what you moved, and being able to observe it in production once it is there. That is the specific gap Koodisi is built to close, and the rest of this post is about how.
An automated rewrite solves the wrong part of the problem
One common approach is a full automated rewrite: convert every BusinessWorks process into a set of microservices, have tooling do most of the translation, and retire the TIBCO license at the end. The cost case is real. The license spend goes away, and the conversion runs faster than a manual rebuild.
The part that’s easy to underweight is what you own afterward. Machine-translated code carries the same undocumented business logic the original did, now in a form no one on the team authored. The estate is still opaque; it has simply changed languages. When something behaves unexpectedly in production, whoever is on call is reading generated code with no clear author and no record of why the original process handled an edge case the way it did. The license line drops. The maintenance line, which rarely appears in the business case, tends to rise.
There’s a more basic issue underneath it. An ESB estate is not one workload. It is a content-based router in one place, a simple file transfer in another, a stateful orchestration that took someone a quarter to get right, and a set of flows that no longer have a consumer at all. A uniform automated conversion treats a routine SFTP pickup and a payment-orchestration state machine as equivalent. They are not, and the flows that matter most are the ones you least want converted without a person in the loop.
A rewrite converts everything at one level. A migration decides, flow by flow, what should move at all.
Moving faster is the wrong target. Moving less of the estate, and understanding what you moved, is the right one.
Sort the estate before you move any of it
Before a single process moves, every BusinessWorks flow should land in one of three buckets. This is the highest-value step in the whole project, and a uniform automated conversion skips it, because its economics depend on treating the estate as undifferentiated volume.
| Bucket | What belongs here | What you do |
|---|---|---|
| Retire | Flows with no downstream consumer, duplicates, one-offs from projects that shipped years ago | Confirm no active dependency, then decommission. |
| Re-home | Standard integration patterns: content-based routing, splitting, aggregation, straight system-to-system moves | Rebuild on Koodisi using native activities and connectors. No hand-written code. |
| Rewrite | Genuinely custom logic: a bespoke transformation, a stateful orchestration, an unusual protocol | Rewrite deliberately, with an engineer and tests. The minority. |
The consistent finding when teams run this pass is how much lands in Retire. A meaningful share of any long-lived ESB estate is flows with no remaining consumer, kept running because decommissioning feels riskier than continuing to pay for them. A migration is the natural point to audit that. Every flow you retire is one you do not assess, convert, test, or carry a license for.
The middle bucket is where Koodisi does the work. The integration patterns an ESB standardized — content-based routers, splitters, aggregators, sagas, circuit breakers — remain first-class on Koodisi as native activities, so a standard flow is rebuilt as configuration rather than transpiled code. The connectors an ESB estate depends on are covered directly: message queues like IBM MQ, ActiveMQ, Kafka, and RabbitMQ, and the systems behind them, including SAP, Oracle, and Db2, over SFTP and the other transports these estates run on. That coverage is what makes re-home, not rewrite, the default for the bulk of the estate. The rewrite bucket, the part that genuinely needs an engineer, stays the smallest of the three.
Most of an ESB estate should be retired or re-homed on native patterns; the slice that truly needs a rewrite is the exception.
The real risk is the cutover you can’t see
The failure that most migration plans underweight is behavioral drift at cutover. A flow moves. It passes testing. Production traffic switches over. Then, weeks later, a downstream system does something it only does at month-end, the new flow handles it slightly differently than the old one did, and a batch of records goes out subtly wrong before anyone notices.
This is the real risk of an ESB-to-cloud migration, and it is largely independent of whether the conversion is correct line for line. The old system’s behavior was never fully specified anywhere except in its own runtime, and you cannot diff a runtime you cannot see. If the answer to “what did this flow do to the records that went out last night” is a manual search through logs in a vendor UI, the migration has reproduced the opacity it was meant to remove.
Koodisi closes that gap by making observability part of the runtime, not an add-on. Every step of a migrated flow emits an OpenTelemetry trace, exported in OTLP to the stack you already run, so you can run the old flow and the new flow in parallel and compare what each did, per record and per step. A failed delivery surfaces with its full payload and can be replayed, rather than registering as a metric that moved. The month-end edge case shows up in a trace in week one, not in a customer report in week three.
You cannot safely retire the old system until you can see the new one at least as well as the old one saw itself.
That is the line most migration plans cross too early.
Land the integrations somewhere you govern them
A migration can end in one of two states. In one, business-critical logic moves into another platform’s database, telemetry stays inside that platform’s dashboard, and the operating cost scales with execution volume. The license is gone, but the estate is opaque again, and an ESB migration is the point where that outcome is easiest to fall into. The longer argument for owning rather than renting your integration layer works through why that matters over time.
Koodisi is built for the other state, where migrated integrations are treated as software you govern. A re-homed flow is a real file in your Git repository, versioned and branchable, with pull requests raised through your existing GitHub or GitLab workflow. Its telemetry is OpenTelemetry, on every tier, exported to your own observability stack rather than held in a vendor console. And because Koodisi prices by capability rather than execution, a month-end traffic spike does not produce an overage invoice, removing one of the costs that made the on-premises estate hard to reason about in the first place.
That combination is available on the Professional tier at $399/mo, with no required implementation partner. The permanent Community tier (30 active workflows and 1,000 executions per month, no credit card) is enough to run the exercise on a real flow: re-home one integration, put it under version control, and confirm you can see exactly what it does in production.
The problem was never that the integrations lived in the wrong place. It was that no one could see into them. Solve for that, and the license savings follow.