A legacy ESB contract renews on a schedule nobody argues with anymore. Core-based licensing, a six-figure floor, a capacity tier you bought two reorganizations ago. Migration finally gets greenlit, a vendor is picked, and six months later the team has moved every flow off the ESB and onto a usage-based iPaaS. The licensing line item is gone. In its place is a bill that reads your traffic before you do.
Migrating off a legacy ESB fixes the licensing problem. It doesn’t automatically fix the pricing problem, and for most teams defaulting to a usage-based destination platform, it just moves the exposure from a contract renewal to a monthly invoice.
This matters because the decision that determines your five-year cost structure gets made in the first month of the project, usually as a byproduct of picking the migration vendor rather than as its own line item. Nobody runs a pricing-model review before the workshop. They run a connector-coverage review, a timeline review, a training review. The billing mechanics of the destination platform get inherited, not chosen.
The migration fixes the wrong layer
Every ESB-migration pitch leads with the same three pain points, and they’re all real: infrastructure you have to run yourself, a release cycle that turns a two-line mapping change into a change-advisory-board ticket, and a licensing model that charges for capacity whether or not you use it. A usage-based iPaaS answers all three. No servers to patch. Ship a flow in a sprint instead of a quarter. No idle capacity tax.
What it doesn’t answer is the question underneath all three: who owns the mechanism that decides what you pay, and what happens when the thing that mechanism measures (your traffic) moves without your permission?
Core-based licensing ties your bill to a number you control: how much capacity you provisioned. It’s expensive and inflexible, but it’s predictable. The invoice doesn’t change because Black Friday happened, or because a customer integration you don’t own started retrying on a five-minute back-off. Usage-based iPaaS ties your bill to a number you don’t control: how many times a workflow executed. That number moves with your product’s success. It also moves with a downstream API’s flakiness, or a retry storm nobody scheduled.
You didn’t remove the pricing risk. You changed which variable it’s indexed to: from a number your finance team picks once a year, to a number your production traffic picks every day.
Per-execution billing turns growth into a liability
The mechanics are simple enough that they rarely get modeled before signing. A workflow gets promoted from staging to production. It works. Traffic to it grows, because the feature it powers is succeeding. The invoice grows with it, at a rate nobody sized during the pilot — because the pilot ran at pilot volume, and the pricing tier was chosen against pilot volume.
Retries make this worse, not better. A downstream system degrades, your workflow retries per its own error handling, and every retry is a billable execution identical in cost to the one that succeeded. The platform is charging you for the outage, not just for the work. A batch job that fans out per-record instead of per-batch multiplies the same problem: one logical run becomes thousands of billable executions, and the unit economics of the workflow were never actually modeled against that shape.
| Usage-metered iPaaS | Feature-tiered (no execution cap) | |
|---|---|---|
| Bill when traffic 10x’s | climbs with volume | flat |
| Retries during an outage | billed per attempt | not billed differently |
| Batch fan-out | billed per record | not billed differently |
| Forecasting next year’s spend | requires a traffic model | requires a feature-roadmap model |
The platform that fixed your licensing lock-in can still leave you unable to answer “what will this cost in Q4,” because the honest answer is “however much your customers use the product.”
None of this shows up in a proof-of-concept. A PoC runs at a fraction of production volume, on a handful of flows, over a few weeks. The pricing model that looked fine at PoC scale is the same pricing model that produces the invoice nobody budgeted for once the migrated flows carry real production traffic. The failure mode isn’t a bad vendor — it’s a pricing model that was never stress-tested against the volume it would eventually meter.
Governance gets bolted on after the platform decision, not designed in with it
The second thing that gets inherited rather than chosen is how governance attaches to the new platform. Most usage-based iPaaS products were built for a different buyer than the one running a legacy-ESB migration — a business user assembling a recipe, not a platform team accountable for an audit trail. RBAC, approval policies, and audit logging get added as the product matures, which means they sit alongside the workflow engine rather than inside it. You get a permissions layer. You don’t get a system where every workflow execution structurally produces the trace, the audit record, and the access log as a side effect of running at all.
That distinction is invisible until an incident forces you to look for something the platform didn’t structurally guarantee. A workflow silently changed behavior last month. Who changed it, and what did the previous version do? In a governance-bolted-on platform, the answer depends on whether someone remembered to check a box, or whether the vendor’s audit log happens to cover the surface you need. In a platform where observability is structural — every step emits a trace, in an open format, into the stack you already run — the answer is a query, not an investigation.
A governance feature you have to remember to enable is not the same thing as a governance property the architecture guarantees.
The ESB you’re migrating off of had this problem in its own way: governance concentrated in a platform team, slow to extend to new use cases, but at least structurally present. The migration is a real opportunity to fix that. It’s also a real opportunity to lose it, if the destination platform treats governance as a layer bolted onto a consumer-grade automation engine instead of something the platform is built around.
What a migration review should actually check
A migration plan built around connector parity and cutover timeline will get every flow moved. It won’t tell you what the mechanism you just adopted is going to cost you in month fourteen, or what it will and won’t let you prove to an auditor. Before signing anything, run the review against the two things the standard migration checklist skips:
- Model the pricing mechanism against your actual production shape, not your pilot shape. Take your highest-volume existing flow, apply its real retry rate and its real fan-out pattern, and price it at 5x and 10x current volume. If the number that comes back depends on a traffic forecast rather than a feature list, you’ve inherited the same risk you were migrating away from.
- Ask what’s structurally guaranteed versus what’s a settings toggle. Audit logging, trace retention, and access control that exist as platform architecture survive a team member forgetting to configure them. Audit logging that exists as an optional add-on doesn’t.
- Check where your workflow logic actually lives. A flow stored in a vendor’s internal database, exportable as a backup file on request, is not the same as a flow that’s a versioned artifact in your own Git repository. One survives the next migration project. The other is the next migration project, five years early.
Where usage-based pricing is genuinely fine
None of this is an argument against usage-based pricing everywhere. A marketing team gluing together three SaaS tools for a monthly report, at a volume that will never meaningfully change, has no exposure worth modeling — the bill is small and stable because the workload is small and stable. The risk shows up specifically at the point a workflow becomes load-bearing: production-critical, subject to retries and growth, the kind of thing an incident review will ask hard questions about. If nothing you’re migrating meets that bar yet, the pricing mechanism matters less. Most legacy-ESB migrations exist precisely because the flows in question already crossed that line.
Check the mechanism, not just the platform
The instinct to leave a legacy ESB is correct. The infrastructure burden, the release cadence, and the licensing floor are real costs, and a usage-based destination genuinely fixes the first two. What it doesn’t fix by default is the third, because the cost risk isn’t gone. It’s been re-indexed to a number you don’t control.
Koodisi prices by capability tier, not by execution: the Professional plan runs at a flat $399/mo with no per-execution billing and no overage invoices, so a workflow that runs 10,000 times behaves the same on your invoice as one that runs 10 million times. Governance isn’t a settings page bolted onto the workflow engine — every application carries OpenTelemetry traces and audit logs as part of the architecture, exportable natively into Datadog, Honeycomb, or whatever you already run. And the workflow itself is a real Git-versioned file in your own repository, branched in-platform, with pull requests running through the GitHub or GitLab flow your team already uses.
If you’re scoping a migration off a legacy ESB, model the destination’s pricing mechanism against your actual production traffic before you sign — not after the first invoice that surprises you. Koodisi’s Community tier is free up to 1,000 executions a month, enough to run that test against a real workflow before committing to anything.