Integration platforms bill for three different things: per core (BizTalk — you buy the peak), per connection (Boomi and most iPaaS — each application endpoint counts against your licence), and per core, like BizTalk but at a fraction of the price and without SQL Server, plus your own cloud consumption (iQBus). Which one is cheapest is not a general question, it is a question about the shape of your estate. A BizTalk estate is typically endpoint-heavy and volume-light — a long tail of ports that touch a system a few times a day — and that is precisely the shape a per-connection meter charges the most for. The point is not that one model is wrong. It is that the model should be chosen against your endpoint count, not against a feature matrix.
A BizTalk team reaching a decision point usually evaluates destinations on capability: what does it connect to, can it do EDI, does it handle our orchestrations. That is the right first question and it is also the one every vendor is prepared for.
The question that decides the five-year number is duller and gets asked later, usually after the contract: what does this platform actually bill for?
Three answers dominate this market, and they are not variations on a theme. They meter fundamentally different things, which means the same estate can be cheap on one and expensive on another for reasons that have nothing to do with how good the product is.
01 / The three meters
What each model is actually charging you for
| Model | Used by | What it prices | Gets expensive when… |
|---|---|---|---|
| Per core | BizTalk Server | Provisioned capacity. You license for peak throughput and pay for it permanently, whatever a normal Tuesday looks like. | …your peak is far above your average, or you need high availability, because the SQL Server behind it scales with you. |
| Per connection | Boomi and most iPaaS | The number of application endpoints. Each one counts against your licence, and edition tiers set how many you get. | …you have many endpoints, regardless of how much traffic each one carries. |
| Per core + your own cloud | iQBus | Cores, at a fraction of BizTalk’s per-core list price, with no SQL Server licence underneath. The Azure infrastructure is billed by Microsoft to your own subscription. | …your throughput grows enough to need more cores. Quiet endpoints add nothing to the licence. |
Boomi does not publish list prices for its integration editions — the only public numeric figure is a pay-as-you-go entry at $99/month plus usage — so the comparison here is about the model, not about who is cheaper on a quote. Your quote is the only number that settles that.
Read that table again with one thing in mind: none of these prices what the business actually cares about, which is messages delivered correctly. They price capacity, endpoints and infrastructure respectively. Every integration platform contract is, in the end, an argument about which proxy for value you are willing to be billed on.
02 / The shape problem
What a BizTalk estate looks like to a per-connection meter
Here is the thing that makes this specific rather than theoretical. BizTalk estates share a characteristic shape, because of how they were built and how long they were built over.
They accumulated. Over fifteen or twenty years, every system that needed to talk to another system got a port. Nobody removed anything, because removing things is risky and nobody was paid to. The result is an estate with a small number of high-volume flows and a very long tail of low-volume ones — the nightly file from a subsidiary, the quarterly feed to a regulator, the one partner who sends eleven messages a week.
This is the whole point, and it cuts both ways honestly:
Per-connection wins when…
Few endpoints · high volume
- You have a modest number of systems talking a great deal to each other
- The estate is modern and consolidated rather than accumulated
- Traffic is spiky — you are not paying for idle capacity
- You genuinely want somebody else to run the runtime
Per-connection hurts when…
Many endpoints · long tail
- Two decades of accumulated ports, most of them quiet
- Trading-partner counts in the dozens or hundreds
- Acquisitions that each brought their own systems
- An estate where nobody has retired anything, ever
The first migration task is the same whichever platform wins: find out how many endpoints are actually live. On a per-connection model that number is not a project metric. It is the price.
Why the inventory comes before the contract
03 / The fair part
Where Boomi is the right answer
We build a competing product, so treat this section with appropriate suspicion — and then check it, because it is the part we would be most embarrassed to have wrong.
Breadth of prebuilt connectors to SaaS
If most of what you are integrating is modern SaaS — CRM, HR, finance platforms with well-behaved APIs — a mature iPaaS connector catalogue is a genuine accelerator, and rebuilding that yourself is not a good use of anyone’s quarter.
You want out of infrastructure entirely
A fully managed multi-tenant service means no runtime to own. If your organisation’s strategic direction is to hold less infrastructure and you are comfortable with your data transiting a vendor’s environment, that is a coherent position and per-connection pricing is the price of it.
Citizen integration is a real goal
If the plan is for business analysts rather than integration engineers to build flows, iPaaS tooling is aimed squarely at that and an ESB is not. Be honest with yourself about whether that plan survives contact with your EDI requirements, but the ambition is legitimate.
The decision may already be made
If a platform has been selected, budget approved and a programme staffed, re-litigating the choice is not useful advice — it is vendor noise. The useful question at that point is a different one, and it is in the next section.
04 / After the decision
The question worth asking mid-programme
Most platform migrations do not absorb the whole estate. They absorb the part that fits the platform’s model well, and then a residue is left over — the flows that were awkward on BizTalk and are awkward everywhere.
They are usually the same five things:
Stateful orchestration with long-running correlation
A process that waits days for a counterparty response, correlates on a business key, and has to survive a restart. Expressible on most platforms; cheap on very few.
The pipeline stages
Disassemble, validate, decode, and the custom component someone wrote in 2011. There is no single equivalent on a workflow-oriented platform — it becomes a chain of steps that a person has to reverse-engineer first.
Message-level tracking as an operational tool
Not dashboards — the ability for an operator to find one message, see what happened to it, fix the cause and resubmit it. BAM and HAT set an expectation that most replacements meet partially.
Data that is not allowed to leave
Clinical records, card data, anything with a residency clause. A multi-tenant service processing that traffic is a conversation with your security function, and sometimes the answer is no.
The long tail itself
The quiet endpoints. On a per-connection model each one carries the same licence weight as a flow moving a million messages, which is exactly the economics that leaves them stranded on the old platform “for now”.
“For now” is the word to watch. A migration that moves 70% of the estate and leaves 30% on BizTalk has not removed the BizTalk licence, the SQL licence, the Windows fleet or the person who maintains them. It has added a platform rather than replaced one, and the business case was almost certainly written on the assumption that it would replace one.
05 / Where we fit
The residue is the case for an ESB, not the whole estate
We are not going to argue that an ESB should absorb your SaaS integration. It should not — that is what an iPaaS is good at, and a coexistence where each platform does what it is shaped for is a better architecture than either one doing everything.
What iQBus is shaped for is exactly the residue above: BizTalk’s capability model kept intact — schemas, maps, orchestrations, pipelines, adapters — running serverless inside your own Azure tenant so the data never leaves, with message-level tracking and one-click resume in the runtime, and a per-core licence, at a fraction of BizTalk’s, that does not care how many quiet endpoints you have.
If you are mid-programme on another platform, the useful conversation is not about switching. It is about what is going to be left over, and whether the plan for it is “an ESB” or “BizTalk, indefinitely, but we stopped saying so out loud”.
Count your live endpoints before you sign anything. On a per-connection model that number is the price, and on any model it is the scope. If you want the platform-cost arithmetic on the BizTalk side of the same question, that is what BizTalk actually costs to keep running.
Frequently asked questions
How is Boomi licensed?
Per connection. Each application endpoint counts against your licence, and the edition tiers determine how many connections you get. Boomi does not publish list prices for its integration editions; the only public numeric figure is a pay-as-you-go entry at $99 per month plus usage, and everything above that is quoted through sales.
What is the difference between per-connection and per-core pricing?
They meter different things. Per-core pricing, as used by BizTalk Server, charges for provisioned capacity — you license for peak throughput and pay for it permanently. Per-connection pricing charges for the number of application endpoints, regardless of how much traffic each one carries. Which is cheaper depends entirely on the shape of your estate rather than on which product is better.
Why does per-connection pricing matter more for a BizTalk estate?
Because BizTalk estates accumulate. Over fifteen or twenty years every system that needed to talk to another system got a port, and almost nothing was ever retired, which produces a small number of high-volume flows and a very long tail of low-volume ones. A per-connection meter charges the same for a quiet quarterly feed as for a flow moving a million messages, so an endpoint-heavy, volume-light estate is the shape that model prices highest.
Is Boomi a bad choice for replacing BizTalk?
No. For estates dominated by modern SaaS endpoints with well-behaved APIs, a mature iPaaS connector catalogue is a genuine accelerator, and for organisations whose strategy is to hold less infrastructure, a fully managed service is a coherent choice. The question worth asking is not whether the platform is good but what your endpoint count does to its pricing model, and what part of the estate it will not absorb.
We have already chosen an iPaaS — is it too late to look at an ESB?
The platform decision is not the question at that point. The useful question mid-programme is what will be left over when the migration completes: stateful long-running orchestration, pipeline stages, message-level operational tracking, data that cannot leave your tenant, and the quiet long tail of endpoints. If the plan for that residue is ‘BizTalk, for now’, the business case has quietly changed from replacing a platform to adding one.
What does an integration platform typically fail to absorb from BizTalk?
Five things recur: long-running stateful orchestration with business-key correlation, pipeline stages including custom components written years ago, message-level tracking that lets an operator find and resubmit a single message, traffic carrying data with residency or regulatory constraints, and the long tail of low-volume endpoints whose per-endpoint licence cost cannot be justified individually.
Can an iPaaS and an ESB run alongside each other?
Yes, and it is often the better architecture. An iPaaS is shaped for SaaS-to-SaaS integration built quickly; an ESB is shaped for governed, high-assurance message flow with orchestration state and message-level traceability. Each doing what it is shaped for beats either one being stretched to cover the whole estate.