There are 43 days left, and the failure mode is not a warning in a log file. It is a refused connection.
On 30 September 2026, Azure Service Bus stops accepting the Service Bus Messaging Protocol. SBMP is the protocol the BizTalk SB-Messaging adapter has always used to talk to Service Bus queues and topics. If you have a send port or receive location running on that adapter and nothing has changed on your side, those flows stop working on the first of October.
This is worth saying plainly because the shape of the deadline is unusual. Most Microsoft end-of-life dates are soft. Support lapses, patches stop, and the software keeps running while you plan. This one is different. The service refuses the connection at the transport layer. There is no degraded mode and no grace period.
Why this catches teams who thought they were fine
BizTalk Server 2020 is in mainstream support until April 2028. Extended support runs to April 2030. Most integration teams have a migration on a roadmap somewhere with 2027 written next to it, and that felt like enough runway.
SBMP retirement lands two years ahead of that roadmap, and it lands on a component nobody has touched in years.
The confusing part is the documentation. Microsoft's published page for the SB-Messaging adapter still carries an Important callout stating that the adapter uses SBMP and does not support AMQP. Read that in isolation and the reasonable conclusion is that you are stuck. That page has not caught up with the fix.
The fix exists. In April 2026 the Azure integration team published a hotfix that adds AMQP support to the SB-Messaging adapter. It is KB5091375, it covers CU6 and CU7, and you get it by opening a support case rather than downloading it. Once installed, AMQP becomes the default transport and SBMP stays available as an opt-in fallback for backward compatibility.
One wrinkle to check rather than assume. The hotfix as originally published was built against the Service Bus SDK that is itself being retired on the same date, with an updated build based on the newer SDK expected around June. If you raise a case, confirm which build you are being given.
This is two retirements, not one
They share a date, which invites teams to treat them as the same problem. They are not, and conflating them wastes the time you do not have.
The protocol retirement is the hard one. After 30 September, SBMP connections are refused. Nothing negotiates, nothing falls back.
The SDK retirement is the soft one. The libraries WindowsAzure.ServiceBus, Microsoft.Azure.ServiceBus and com.microsoft.azure.servicebus stop receiving support and updates. They keep working if they are running over AMQP. That is a modernisation task with a real cost attached, but it is not an outage.
So the triage order is transport first, packages second. A modern package reference does not mean you are safe, and a legacy package reference is not automatically an incident.
What to check, and in what order
BizTalk is the obvious exposure but it is not the only one. On .NET Framework, WindowsAzure.ServiceBus defaults to SBMP. AMQP 1.0 has been available since version 2.1, but as an opt-in. Plenty of production deployments never flipped it, and the people who made that decision have moved on.
Start with an inventory rather than a fix. You cannot patch what you have not found.
Look at every BizTalk send port and receive location using SB-Messaging, and note which application owns it. Look for connection strings containing TransportType=NetMessaging, which is the legacy transport setting. Look for sb:// endpoints in configuration that nobody has audited. Grep your solutions for references to the three retiring packages. If you have network traces or connection logging on the Service Bus side, use them, because observed protocol beats inferred protocol every time.
Then check your egress rules. AMQP needs outbound TCP on 5671 and 5672, and HTTPS on 443 is generally required alongside it for management operations and token acquisition. If your firewall was opened years ago for a protocol that is about to disappear, the port list may not cover what you are about to switch to. This is a boring failure and an easy one to hit at 2am on 1 October.
Three paths, and how to pick
Install the hotfix and move the adapter to AMQP. This is the right answer for most teams. It is the smallest change that removes the deadline, it keeps your existing orchestrations and maps untouched, and it buys you back the runway you thought you had. Raise the support case now, because the case queue is not going to get shorter in September. Install in a lower environment, run your highest-volume flows through it, and watch for message size behaviour in particular.
Put an intermediary in front of BizTalk. If the hotfix is not viable, and there are legitimate reasons it might not be, a Logic App or Azure Function can consume from Service Bus over AMQP and hand the payload to BizTalk through an adapter that is not going anywhere. File, SFTP and HTTP all work for this. You are adding a hop, some latency, and a new thing to monitor. It is a workaround and it should be labelled as one, but it is a defensible bridge while the real migration gets funded.
Migrate the flow to Azure Integration Services. This is where you are going eventually. It is not where you are going by 30 September. Published migration timelines for BizTalk estates run from 12 to 18 months at the low end and 18 to 36 months for complex landscapes, and those numbers are honest ones. Anyone offering you a full migration inside six weeks is selling you an outage with a project plan attached.
The trap here is a specific kind of ambition. A deadline arrives, someone reasonably points out that the tactical fix does not solve the strategic problem, and the tactical fix gets deferred into a migration programme that has not been scoped. Then September happens.
Do the small thing by the deadline. Scope the big thing properly afterwards.
The part that actually matters
If your BizTalk estate is old enough to still be running SB-Messaging on SBMP, the odds are good that nobody currently employed knows every flow it carries. That is the real finding here, and the protocol deadline is just what surfaces it.
The inventory work has value beyond this September. When the 2028 conversation starts in earnest, the first question anyone asks is what BizTalk is actually doing, and most organisations cannot answer it. Doing that discovery now, under a deadline that forces it, is a better outcome than doing it under a migration budget that assumed you already knew.
Forty-three days is enough for the hotfix. It is enough for the inventory. It is not enough for both plus a migration.
Sources
- Service Bus SBMP Retirement: What BizTalk Server 2020 Customers Need to Know, Microsoft Integrations on Azure blog, April 2026. Hotfix KB5091375, CU6 and CU7 coverage, AMQP as default transport.
- Azure Service Bus FAQ, Microsoft Learn. SBMP retirement notice, supported protocols and port requirements.
- SB-Messaging Adapter, Microsoft Learn. The page still states the adapter does not support AMQP.
- Some Azure Service Bus SDK libraries will be retired on 30 September 2026, Microsoft Messaging on Azure blog. The SDK retirement, distinct from the protocol retirement.
- Performance best practices, Azure Service Bus, Microsoft Learn. SBMP availability on .NET Framework and AMQP as the .NET Standard default.
