Microsoft has confirmed BizTalk Server 2020 is the final version and designates Azure Logic Apps as the successor. But publicly observable migrations — job postings, vendor case studies, contract requisitions — show organisations moving to Boomi, AWS-hosted rehosts, MuleSoft, Apache Camel and Kafka, and smaller European platforms, in numbers comparable to those visibly moving to Logic Apps. That is a sample of what is visible, not market share, and it should not be read as one. What it does establish is that the destination is genuinely open, that Microsoft is now industrialising migration away from every legacy ESB rather than only its own, and that the useful question is not which platform is best but which shape of estate suits which destination.
The BizTalk conversation has a default assumption baked into it: Microsoft named a successor, therefore the migration is to that successor, therefore the only remaining questions are timing and cost.
The first half of that is true. Microsoft has confirmed BizTalk Server 2020 is the last and final version, and designates Azure Logic Apps as the path forward. Microsoft has also published an official migration tool that converts BizTalk orchestrations into Logic Apps workflows, which is real and getting better.
The second half is an assumption, and it is worth checking against what organisations are visibly doing.
01 / What is observableSeven destinations, from public evidence
Each row is one organisation we can see moving off BizTalk, from public job postings, contract requisitions and published case studies. Where the organisation has not published its own migration we do not name it, because a job posting is evidence of work happening, not a statement anyone has authorised.
| Destination | Good if | What it suggests |
|---|---|---|
| BoomiEvidence: job posting, large enterprise programme | Your estate is mostly SaaS and API endpoints and you want a managed iPaaS. Check what per-connection licensing does to your long tail of quiet flows first. | A well-resourced programme that chose a non-Microsoft iPaaS with the Azure option available. |
| AWS (rehost)Evidence: four contract requisitions | A data-centre exit has a hard date and the integration migration is not ready. It buys time; it does not modernise anything. | Not a migration at all. A lift-and-shift that preserves every end-of-life problem on different infrastructure. |
| MuleSoftEvidence: job posting, large insurer | You already run MuleSoft and API-led integration is the company standard. | A half-finished migration, which is the most common real-world state and rarely the planned one. |
| Apache Camel / KafkaEvidence: search result only ⚠ weaker than the rest | You have a strong engineering team, want open source, and your flows are moving toward event streaming. | An open-source destination. Treat this row as a signal, not a confirmed migration. |
| FrendsSkövde Municipality (SE) · published case study | You have a few hundred integrations, a fixed deadline set by another project, and C# code worth reusing. They moved ~200 integrations in six months. | Smaller regional platforms win real estates, and the trigger was not BizTalk. |
| Ghost NodesTransdev Sverige AB · published case study | You have a large estate and want your own IT team to carry most of the move. They retired 300+ integrations, about 70% of the work done in-house. | Large estates are migratable, in parallel, mostly in-house. |
| iQBus (ours)Novelty, Inc. · our own case study | You don’t want to lose your BizTalk experience, and you need a fast, mostly automated migration with data that never leaves your tenant. | A platform built on the BizTalk model lets an estate keep most of its existing work. This is our product, so weigh it as vendor evidence, like the two case studies above. |
| Azure Logic AppsEvidence: two confirmed migrations | Your flows are mostly straightforward and API-based, and you want Microsoft’s own path with its migration tooling. | Real, and fewer than the default assumption implies. |
This is a sample of what is publicly visible — job boards and case studies — not a market survey. Organisations that migrate quietly, or with an incumbent partner, or without hiring, do not appear in it at all, and Microsoft-ecosystem migrations are exactly the kind most likely to be invisible. It shows the diversity of destinations, not their market share, and anyone using it to claim “most BizTalk shops reject Azure” is misusing it.
Three conclusions the evidence supports
The destination is open, so the evaluation is worth running
If you assumed the answer was decided for you, it is not. Organisations comparable to yours have looked at the same designated successor and chosen otherwise, for reasons ranging from existing platform investments to pricing model to where the data is allowed to sit. That is a reason to run a real evaluation, not a reason to reject Azure.
Microsoft is building an exit funnel from every legacy ESB
Microsoft’s Logic Apps Migration Agent targets MuleSoft, Boomi, TIBCO, IBM IIB/ACE and Workato as well as BizTalk. Read that carefully: Microsoft is industrialising migration into Logic Apps from the whole legacy ESB market. It is a competitive play, not just a duty of care to existing customers — which is useful context when reading anyone’s migration guidance, including Microsoft’s and including ours.
Large estates do move, and mostly in-house
The most encouraging number in the set is that ~70% of a 300-integration migration was executed by the customer’s own IT team. That is a competitor’s published case study, which makes it more credible rather than less — the fear that these projects require an army of external consultants is not supported by the evidence.
Rehosting to another cloud is a deferral
One row in that table is different in kind, and it deserves its own warning because it is the easiest option to get approved.
Moving BizTalk applications onto cloud-hosted virtual machines is a rehost. The MSIs still deploy, the bindings still update, the environments still get validated — the platform is unchanged, running on a different landlord’s hardware.
It is worth being precise about why this matters rather than just disapproving of it. A rehost:
- keeps every support-end date exactly where it was;
- keeps the per-core licensing, and often makes it worse, because cloud VM sizing rarely matches the four-core floor neatly;
- keeps the operational model — the MSIs, the deployment windows, the host restarts;
- and moves you outside the ecosystem the vendor’s own migration tooling is built for.
Nobody sets out to do this. It happens because a data-centre exit has a hard date and an integration migration does not, so integration gets carried along in the infrastructure programme. If that is your situation, the useful move is to name it as a deferral with an expiry rather than let it be recorded as modernisation complete.
04 / ChoosingWhich shape of estate suits which destination
The genuinely useful question is not which platform is best. It is which properties of your estate the destination has to accommodate.
| If your estate is… | Look hardest at… | Because |
|---|---|---|
| A few dozen straightforward point-to-point flows, mostly modern APIs | Azure Logic Apps on its own | You may not need an ESB at all, and adding one is cost without benefit. We will say so in an assessment. |
| Dominated by SaaS endpoints with good APIs, and you want out of infrastructure entirely | A managed iPaaS | Connector breadth is a genuine accelerator. Check what per-endpoint licensing does to your long tail first. |
| Heavy on orchestration state, pipelines, EDI partner management and message-level tracking | An ESB — ours or otherwise | These are the capabilities that have to be assembled from parts on a workflow-first platform, and assembling them is where budgets overrun. |
| Carrying data that cannot leave your tenant | Anything that deploys into your own subscription | Multi-tenant processing of regulated data is a conversation with your security function that you may not win. |
| Endpoint-heavy and volume-light — a long tail of quiet ports | Flat-fee or consumption models | Per-endpoint pricing charges the same for a quarterly feed as for a flow moving a million messages. See what per-connection pricing does to an estate built on endpoints. |
| Facing a data-centre exit before it is ready to migrate | A rehost, named honestly as a deferral | Legitimate as a tactic with an expiry date attached. Dangerous when recorded as the modernisation itself. |
The disclosure
We build iQBus, so the third and fourth rows of that table are the ones we sell into. It would be dishonest to present this post as neutral, and it would be equally dishonest to pretend the first two rows do not exist — the fastest way to lose a technical evaluation is to claim an ESB is the answer to an estate that does not need one.
What we would actually argue from the evidence above is narrower: the destination is not decided for you, and the evaluation is worth doing properly. Organisations with the same designated successor and the same deadline have reached seven different answers. The variable is the estate, not the vendor’s roadmap.
iQBus installs free from the Azure Marketplace into your own subscription, which makes it cheap to include in an evaluation rather than take on trust. If what you need first is the inventory that makes any evaluation meaningful, that lives on the services side: the migration methodology.
Frequently asked questions
Is Azure Logic Apps the only option for replacing BizTalk?
No. Microsoft has confirmed BizTalk Server 2020 is the final version and designates Azure Logic Apps as the successor, and for many estates that is the right destination. But publicly observable migrations show organisations moving to Boomi, AWS-hosted rehosts, MuleSoft, Apache Camel and Kafka, and smaller regional platforms as well. The destination is genuinely open, which is a reason to run a real evaluation rather than a reason to reject Azure.
Do most organisations migrate BizTalk to Azure?
That is not a question public evidence can answer. What is visible — job postings, contract requisitions and published case studies — shows a diversity of destinations, but organisations that migrate quietly or through an incumbent partner never appear in that sample at all, and Microsoft-ecosystem migrations are among the most likely to be invisible. Treat any tally drawn from public sources as evidence of variety, never as market share.
Is moving BizTalk to AWS or another cloud a migration?
No, it is a rehost. Running the same BizTalk Server, SQL Server and Windows stack on cloud virtual machines keeps every end-of-life date exactly where it was, keeps the per-core licensing, keeps the MSI-and-restart operational model, and moves you outside the ecosystem the vendor’s own migration tooling targets. It is a legitimate tactic when a data-centre contract expires before an integration migration is ready — provided it is recorded as a deferral with an expiry date rather than as modernisation complete.
What does Microsoft’s Logic Apps Migration Agent tell us?
That the play is broader than BizTalk. The agent targets MuleSoft, Boomi, TIBCO, IBM IIB/ACE and Workato in addition to BizTalk, which means Microsoft is industrialising migration into Logic Apps from the entire legacy ESB market. That is useful context when reading anyone’s migration guidance — Microsoft’s, and equally ours.
Can a large BizTalk estate be migrated by an in-house team?
The published evidence says yes. A public transport operator retired more than 300 BizTalk integrations across 40+ connected systems, running both platforms in parallel, with roughly 70% of the work executed by its own IT team. That is a vendor’s case study about a competitor’s platform, which makes it more useful as market evidence rather than less — the assumption that these projects require an army of external consultants is not supported.
How do we choose between an iPaaS, Logic Apps and an ESB?
By the shape of the estate rather than by feature comparison. A few dozen straightforward point-to-point flows over modern APIs may not need an ESB at all. An estate dominated by SaaS endpoints with good APIs suits a managed iPaaS, subject to what per-endpoint licensing does to your long tail. An estate heavy on orchestration state, pipelines, EDI partner management and message-level tracking is where an ESB earns its cost, because those are the capabilities that otherwise get assembled from parts. And anything carrying data that cannot leave your tenant narrows the field to platforms that deploy into your own subscription.
How long does a BizTalk migration take?
Published estimates put typical enterprise migrations at six to eighteen months, with estates carrying hundreds of interfaces at the twelve-to-eighteen end. The Frends and Ghost Nodes case studies above are consistent with that: around 200 integrations moved in six months in one, and 300+ over a longer parallel-run programme in the other.