Microsoft has confirmed that BizTalk Server 2020 is the last and final version, that mainstream support ends April 11, 2028, and that Azure Logic Apps Standard is the named successor. What gets skipped is the cost of that successor: BizTalk shipped a message store, publish-subscribe routing, transactional delivery, pipelines and BAM as part of the product. Logic Apps expects you to assemble those from other Azure services and your own code. That gap — not the artifacts — is where migration budgets go.
Three of those four statements are settled facts, not readings of tea leaves. The fourth is the one that determines your budget: what does moving to the named successor actually involve?
Microsoft’s own migration guide answers that more honestly than most vendor blogs do — including the parts that cost money. Almost nobody reads it. So this post is mostly Microsoft’s documentation, read the way an architect reads it rather than the way a slide deck summarises it.
01 / The facts
What Microsoft actually said
Three separate statements, routinely conflated into one:
Two details get lost. First, Host Integration Server is being decoupled from BizTalk and will ship as a standalone product with its own lifecycle — so if your mainframe or midrange connectivity runs through HIS, that slice of your estate is on a different clock than the rest of it.
Second, and more expensively: the real deadline is 2028. Extended support buys hotfixes if you pay for them. It is not a platform you would choose to build the next five years of your business on.
02 / The catch
“Successor” does not mean “upgrade”
Here is the part that surprises teams three months into a migration project.
BizTalk is a product. You install it, and a large amount of infrastructure arrives with it: a persistent message store, a publish-subscribe routing engine, transactional delivery, pipelines, tracking, a rules engine. You then configure that infrastructure. Most of what a BizTalk estate does is expressed as configuration and artifacts, not as application code.
Azure Logic Apps Standard is a platform. A genuinely good one — better than BizTalk at many things, and Microsoft’s list of those things is fair. But the infrastructure BizTalk handed you is not in the box. It is assembled from other Azure services, and the behaviour you relied on is something you now design, provision and write.
03 / The bill
Five things that become custom development
Every one of these comes from Microsoft’s own migration documentation. Expand the evidence under any card to read it in their words.
The MessageBox and publish-subscribe routing
BizTalk publishes messages, evaluates subscriptions against context properties, and routes. In Logic Apps you provision Azure Service Bus, then re-express every subscription as topic subscriptions with filters over user properties you define. Content-based routing stops being configuration and becomes infrastructure you architect, deploy and govern.
Microsoft’s words
“Compared to the BizTalk Server messaging engine, Azure Logic Apps Standard uses connectors and external messaging services to implement messaging patterns alongside workflow orchestration… Unlike BizTalk Server, messaging is decoupled from the workflow engine.“
Exactly-once becomes at-least-once, plus your code
BizTalk gave you transactional, durable, ordered delivery as a property of the platform. Logic Apps hands you at-least-once and tells you to handle the rest. Every write path that cannot tolerate a replay now needs code that did not exist before — and testing for a failure mode BizTalk absorbed silently.
Microsoft’s words
“Resubmission might cause the workflow to process the same message again, so make sure your designs assume at-least-once processing and implement idempotency. For example, use deduplication keys, upserts, or exactly once effects at the destination.”
Pipelines
There is no pipeline construct. Decoding, disassembly, validation, party resolution and custom components are re-implemented as workflow actions, inline code or Azure Functions. Custom pipeline components in particular become custom software — with their own repo, build, deployment and on-call story.
What Microsoft offers instead
The documented options for shaping data are built-in data operations, expressions, Liquid templates, and Parse XML / Compose XML with schema. Useful primitives — but primitives, not a pipeline.
BAM
Business Activity Monitoring has no native replacement. Microsoft points to Azure Business Process Tracking — where you model business processes as stages and instrument them, which is a design-and-build exercise — or to a third-party product. Logic Apps does give you excellent per-run technical telemetry, and it is genuinely better than trawling HAT. It is a different thing from “which purchase orders from this trading partner are stuck, and for how long.”
Microsoft’s words
Microsoft’s guidance names Azure Business Process Tracking, in which “a business process is a series of stages that represent the tasks flowing through real-world business scenario” — plus an external option from a third-party vendor. Neither is a lift-and-shift of BAM.
SOAP, tooling and deployment
SOAP endpoints go through a custom connector or API Management. Development moves from Visual Studio to VS Code. MSI packages and binding files give way to workflow definitions, externalised connections and infrastructure-as-code. Each is defensible on its own merits and most teams end up preferring the new model — but all of it is work, and none of it is the work of moving your integrations.
Unlike BizTalk Server, messaging is decoupled from the workflow engine.
Microsoft Learn — BizTalk Server migration guide
04 / The credit
What genuinely carries over
We would rather you trusted the section above, so here is the honest other side of the ledger.
Carries forward
little or no rework
- XSD schemas — largely as-is; Microsoft publishes many BizTalk EDI schemas in its public Integration repo
- XSLT maps — and Standard workflows can call .NET Framework assemblies from XSLT, so functoid helper libraries survive
- BRE policies — the Azure Logic Apps Rules Engine includes the BizTalk BRE runtime (currently XML and .NET Framework facts)
- HL7, MLLP, SWIFT — direct equivalents exist
- Common orchestration shapes — receive, send, decide, parallel, loop
You build
design, code, operate
- Publish-subscribe routing on Azure Service Bus
- Idempotency and deduplication on every replay-sensitive write
- Pipeline behaviour as actions or Azure Functions
- Business-level tracking to replace BAM
- SOAP connectivity via custom connector or API Management
- Uncommon orchestration shapes — tooling emits placeholders with comments for a developer to finish
And several things are simply better on the new platform: REST and OAuth2 connectivity, hundreds of managed connectors, consumption pricing instead of building for peak, run history you can read without remoting into a server, and no Windows fleet to patch.
05 / The decision
Which path fits your estate
The question is not “Microsoft or not Microsoft.” Both destinations are Azure, and anyone framing this as leaving the Microsoft ecosystem is selling you something. The real question is narrower: does the platform you adopt match the workload you are moving?
Tick everything that is true of your estate
0–2 ticks: your estate is closer to modern workflow automation than to classic middleware. Logic Apps Standard is a strong destination and the rebuild is proportionate — take it.
3 or more: the honest cost of the named successor is a multi-year re-engineering programme, and the artifacts are the small part of it. The expensive part is rebuilding the behaviour the platform used to provide. That is the case a parity platform exists for.
06 / The alternative
Where Art2link ESB fits
Art2link ESB exists for that second case. Same Azure foundation, built by the BizTalk Server consultant-architects at Cerebrum City, and it keeps the constructs rather than asking you to re-derive them:
- Schemas stay XSD; maps are XSLT 3.0 with custom functions
- Pipelines are pipelines — deterministic receive and send flow, not reassembled from workflow actions
- Tracking is built in — tracking UI, OpenTelemetry, bottleneck detection, one-click replay — rather than a monitoring project
- Ports and adapters, 200+ of them, alongside Azure-native connectors
- Runs serverless in your own Azure tenant with Entra ID; messages and data never leave your environment
- Configuration changes go live with no builds and no restarts
- Art2link Migration AI converts schemas, maps, pipelines and orchestrations automatically — every conversion reviewed by a senior architect before it ships
Roughly ~80% of BizTalk artifacts reused, with zero downtime at cutover. The numbers and the method are in the case study on the BizTalk alternative page.
If you know BizTalk, you already know Art2link. That is the entire product thesis, and it is the opposite of a rewrite.
07 / Next
Where to start
Whichever destination you pick, the first task is the same: inventory the estate, then price both paths against it. That is a planning question rather than a platform one, and our colleagues at Cerebrum City have written it up properly — how to sequence the programme, what a phased cutover and parallel run actually involve, and why 2028 is the date that matters: BizTalk 2020 is the final version — what it means for your migration plan.
Either way, we will do the inventory with you at no cost. You will speak with a senior integration architect, not an SDR — and you get the artifact inventory, AI-conversion coverage and a phased plan back regardless of what you decide afterwards.
FAQ
Frequently asked questions
Is BizTalk Server 2020 really the last version?
Yes. Microsoft has stated that BizTalk Server 2020 is the final version of the product. There is no BizTalk 2022 or later on the roadmap, and Microsoft’s guidance directs customers to Azure Logic Apps Standard as the successor.
When does BizTalk Server 2020 support actually end?
Mainstream support ends April 11, 2028. Paid Extended Support runs from April 2028 to April 9, 2030, after which the product is fully unsupported. Plan against 2028 — extended support buys hotfixes, not a platform to build on.
Did Microsoft name a successor to BizTalk Server?
Yes — Azure Logic Apps Standard, part of Azure Integration Services. Microsoft’s migration guide describes it explicitly as the successor to BizTalk Server.
If Logic Apps is the successor, why isn’t migrating to it straightforward?
Because BizTalk shipped infrastructure that Logic Apps expects you to assemble. Microsoft’s own documentation notes that messaging is decoupled from the workflow engine (so publish-subscribe requires Azure Service Bus and hand-built topic filters), that you should assume at-least-once delivery and implement idempotency yourself, and that BAM has no native equivalent. Pipelines have no direct construct. Those four items are where migration budgets are spent.
What carries over from BizTalk to Logic Apps without rework?
XSD schemas largely reuse as-is. XSLT maps can carry forward, and Standard workflows can call .NET Framework assemblies from XSLT. BizTalk BRE policies can be reused because the Azure Logic Apps Rules Engine includes the BRE runtime, currently for XML and .NET Framework facts. HL7, MLLP and SWIFT have direct equivalents.
How is Art2link ESB different from migrating to Logic Apps?
Art2link ESB keeps the BizTalk constructs instead of replacing them: XSD schemas, XSLT 3.0 maps, deterministic pipelines, ports and adapters, and built-in end-to-end tracking — running serverless inside your own Azure tenant. Same Azure foundation, positioned for ESB workloads that need governance, transaction tracking and exception routing rather than cloud-first workflow automation.
Where does Art2link ESB run, and who can see our data?
Art2link deploys inside your own Azure tenant with Entra ID integration, encryption and audit controls. Your messages and data never leave your environment. It runs serverless and scales to zero, so there is no Windows fleet to patch and no capacity to buy for peak.
Run this on Art2link instead of legacy middleware.
One-click install from the Azure Marketplace. Same standards, modern runtime.