For years, “is BizTalk being discontinued?” was a question you could only answer by inference. Microsoft had shipped no successor to BizTalk Server 2020, kept extending support dates, and pointed customers at Azure Integration Services without ever saying the word final.
That ambiguity is gone. In its BizTalk Server product lifecycle update, Microsoft stated plainly that BizTalk Server 2020 will be the final version of BizTalk Server, and named Azure Logic Apps as its successor. The support runway is now fixed and public.
If you own an integration layer that runs on BizTalk, this is the clearest planning signal you have had in a decade. Here is what it actually says, and what it does not.
The dates, exactly
Three dates matter, and they are commonly conflated:
| Lifecycle phase | End date | What you still get |
|---|---|---|
| Mainstream support | April 11, 2028 | Security and non-security updates, plus Microsoft Customer Service & Support |
| Extended support | April 9, 2030 | Security updates, CSS support, and paid fixes for non-security hotfixes |
| End of support | April 10, 2030 | Nothing. No updates, no technical assistance |
Two things follow from that table that are worth stating out loud.
First, BizTalk does not stop working on April 10, 2030. Your orchestrations will keep running. Microsoft is explicit about this: workloads continue, they simply run without servicing. Anyone selling you a cliff-edge outage story is selling.
Second, the meaningful date for most enterprises is April 2028, not 2030. After mainstream support ends, non-security hotfixes become a paid engagement. If your integration layer carries EDI, HL7, or payment traffic, “we can buy a fix if we need one” is a different risk posture than “fixes are included,” and your auditors will read it that way.
The date that matters for most enterprises is 11 April 2028, not 2030. After mainstream support ends, non-security hotfixes become a paid engagement — a different risk posture for an integration layer carrying EDI, HL7, or payment traffic, and one your auditors will read that way.
What Microsoft is recommending, and where it is thin
Microsoft’s guidance is that Logic Apps — as part of Azure Integration Services alongside API Management, Service Bus, and Event Grid — is the destination, and that most BizTalk maps, schemas, rules, assemblies, and custom code can be reused with the help of Microsoft and partner tooling.
The reuse claim deserves nuance, because it is where migration plans most often go wrong.
Reuse of artifacts is real. XSD schemas transfer. BizTalk maps can frequently be carried into Logic Apps’ data mapper with modest rework. Custom .NET helper assemblies can often be lifted into Azure Functions almost unchanged.
Reuse of architecture is not. BizTalk’s messagebox, subscription-based routing, convoy patterns, long-running stateful orchestration, and the ports-and-pipelines model have no single Azure equivalent. They decompose into several services, and deciding how they decompose is design work — not conversion work. Tooling that converts orchestrations into workflows gets you a running artifact; it does not get you an architecture that survives production volume.
That distinction is the entire difference between a migration that lands and one that stalls at 70% for a year.
Why the real constraint is people, not dates
Here is the part no lifecycle table captures.
The scarce resource in a BizTalk migration is not Azure capacity or budget. It is the small number of people who know why a particular orchestration has a three-retry loop with a nine-minute delay, or which trading partner silently depends on a malformed segment your pipeline quietly tolerates.
That knowledge is mostly undocumented and mostly in the heads of engineers who have been maintaining the estate for a decade. Every year between now and 2030, some of them retire, change jobs, or simply forget. The migration does not get technically harder over time — it gets epistemically harder. You lose the ability to know what you are replacing.
The migration does not get technically harder over time. It gets epistemically harder — you lose the ability to know what you are replacing.
This is why the strongest argument for starting now has nothing to do with support dates. It is that a migration run while the institutional knowledge is still in the building is a fundamentally cheaper and lower-risk project than the same migration run in 2029.
The four options, honestly
Stay put until the deadline. Costs nothing this budget cycle. Rational if your estate is genuinely small or the business is consolidating onto another platform anyway. Irrational at scale, because you convert a roadmap into a deadline, and deadline-driven integration projects are where the expensive mistakes live.
Rehost BizTalk on Azure VMs. Solves a datacenter problem, not a support problem. The 2030 clock keeps running, you now pay cloud infrastructure costs for a platform with no future, and you have spent modernization budget without modernizing. Defensible only when a hardware refresh or datacenter exit is forcing your hand.
Rebuild on Azure Integration Services. The right destination for a large share of typical BizTalk workloads: fully supported, Microsoft-native, no infrastructure to manage. It is a rebuild, not a conversion, and you should budget it as one. Watch consumption pricing at high message volumes — it is not automatically cheaper.
Rebuild, with a purpose-built ESB where Logic Apps leaves gaps. Three patterns consistently expose those gaps: very high-throughput messaging, complex or heavily-conditional mapping, and long-running stateful orchestration. This is why we built Art2link ESB — an Azure-native middleware layer for the workloads that Logic Apps handles awkwardly — rather than forcing every pattern through a tool that fits most of them but not all.
What to do in the next ninety days
You do not need a migration plan in ninety days. You need enough of an inventory that the migration plan is possible to write.
- Count the interfaces. Not orchestrations — interfaces. How many trading partners, how many receive locations, how many send ports, and what is the actual message volume per day on each.
- Find the undocumented behavior. For each high-volume interface, ask the engineer who maintains it what would break if it were rebuilt from the schema alone. Write the answers down. This is the single highest-value artifact you will produce.
- Classify by pattern, not by system. Group interfaces into simple pass-through, mapped request/response, high-throughput one-way, and stateful orchestration. Your Azure target differs per group, and so does the difficulty.
- Pick one low-risk interface and actually move it. A single interface running in parallel on Azure teaches you more about your real timeline than three months of estimating.
That is the assessment. It is not glamorous work, and it is the thing that converts a 2030 deadline into a 2027 roadmap.
Where we sit in this
Cerebrum City is a Microsoft V-TSP–recognized BizTalk specialist. We have spent two decades running BizTalk Server in enterprise production — for Humana, Deloitte, JetBlue, U-Haul, and others — which means we have also spent two decades collecting the failure modes that only show up at volume.
Most cloud partners bidding on BizTalk migrations have never operated BizTalk at scale. That is not a knock on their Azure skills; it means the part of the project that requires knowing what BizTalk was actually doing gets learned on your estate.
If you want your own estate inventoried, mapped to Azure targets, and sequenced into waves, that is what our courtesy assessment does — no obligation, on your schedule.
Sources
Jorge Pastorini · Cerebrum City
Cerebrum City is a Microsoft V‑TSP–recognized BizTalk specialist in Atlanta, Georgia, with two decades running BizTalk Server in enterprise production for clients including Humana, Deloitte, JetBlue, and U‑Haul.
Want this mapped against your BizTalk estate?
We inventory your ports, orchestrations, maps, and adapters, flag the interfaces most likely to break, and hand back a staged Azure roadmap. No obligation.
