OnLTS
Retirement: September 30, 2026

Microsoft.Azure.ServiceBus and WindowsAzure.ServiceBus are retired on September 30, 2026.

I move your code to Azure.Messaging.ServiceBus for a fixed price. You get a pull request with your own tests passing, and the runtime details that break after the build (settlement, lock renewal, message bodies) handled.

What the retirement means for your app

  • No more support or fixes for Microsoft.Azure.ServiceBus and WindowsAzure.ServiceBus, security fixes included. The packages keep loading, but you are on your own.
  • SBMP stops working. WindowsAzure.ServiceBus uses the SBMP protocol by default. Connection strings without TransportType=Amqp are on SBMP, and Microsoft ends SBMP support on the same date.
  • Azure Functions with the Service Bus extension 4.x or older use the retired types, and the in-process model itself ends support on November 10, 2026.
  • The new SDK behaves differently in ways that compile fine: auto-complete, a 5 minute lock renewal default, message bodies sent with BrokeredMessage, and MessageId no longer generated for you.
  • Not affected: WindowsAzure.ServiceBus used for WCF Relay, which Microsoft keeps supporting until further notice.

Sources: Service Bus FAQ (retirement notice) · WindowsAzure.ServiceBus and SBMP · Official migration guide · WCF Relay exception (Microsoft Q&A)

Fixed price, three sizes

Prices in USD, paid through Upwork. You know the full cost before anything starts.

Every tier includes

  • Every sender, receiver and handler moved to ServiceBusClient, ServiceBusSender, ServiceBusReceiver or ServiceBusProcessor
  • One shared client per app, registered in dependency injection
  • Auto-complete, concurrency and lock renewal set explicitly per handler
  • UserProperties, Label, dead-letter headers and exception handling moved to the new API
  • Notes on what changed and what to watch on deploy
  • 14 days of fixes for anything the migration caused
Starter

One service

US$390

Delivery in 5 days from access.

  • One project using Microsoft.Azure.ServiceBus
  • Up to 10 senders, receivers or handlers
  • Queues and topics, without sessions
  • 1 revision
Order one service
Advanced

Full migration

US$1,290

Delivery in 12 days from access.

  • Up to 12 projects
  • WindowsAzure.ServiceBus and SBMP, BrokeredMessage bodies, NamespaceManager
  • Transactions, and a rollout plan for old and new message formats side by side
  • 3 revisions
Order full migration

Delivery in business days from access. If your code turns out bigger than the tier you bought, I tell you before starting and you choose: pay the difference or get a full refund.

Not included

  • Deploying to your servers or touching production
  • Changes to the Service Bus namespace itself (tiers, networking, access policies)
  • Moving the function app to the isolated worker model (a separate fixed-price job)
  • WCF Relay code, which is not part of this retirement

How I work

Everything happens in writing, on your schedule. A 15-minute call is available if you want one, never required.

  1. Read-only access. Add a read-only collaborator on GitHub, Azure DevOps or GitLab, or send a zip. No production credentials and no secrets.
  2. The work gets done. A set of AI coding agents does the scanning, the code changes and the test runs. I review every change and sign off before you see it.
  3. You get a pull request. With notes on what changed, what to watch on deploy and the results of your own tests. Without write access, you get a patch file.
  4. You deploy. I never touch production: no deploys, no production databases, no infrastructure changes. You merge and release when it suits you.

The job is accepted when the solution builds and your existing tests pass. Tests that already failed before are listed in the notes and stay out of scope. No automated tests? We agree on a short smoke checklist before I start, and that becomes the acceptance criterion.

Free first step: check your solution yourself

Net10Check is a free command-line tool. Run it in your solution folder and it lists every project that references Microsoft.Azure.ServiceBus or WindowsAzure.ServiceBus, along with in-process Azure Functions and the other things that block .NET 10. It runs locally and uploads nothing.

dotnet tool install -g Net10Check
net10-check

If the report is short, you can probably do it in-house. If it is long, send it to me and I will tell you, for free, which tier fits. Message me on Upwork.

FAQ

My app uses WindowsAzure.ServiceBus only for WCF Relay.

Then this retirement does not apply to it. Microsoft confirmed that WindowsAzure.ServiceBus stays supported with WCF Relay until further notice. If the same project also uses queues or topics, only that code needs to move.

We cannot finish before September 30. Is there a stopgap?

For WindowsAzure.ServiceBus, adding ;TransportType=Amqp to the connection string moves it off SBMP, with some documented behavior differences. It buys time, it is not the migration. I can tell you in the first day whether it applies to you.

There are messages in our queues sent by the old code.

Bodies created with new BrokeredMessage(object) are serialized in a format the new SDK does not read by itself. The Advanced tier includes reading both formats until the queues are clean, and the order in which to deploy consumers and producers.

Which tier do I need?

Run Net10Check and send me the output, or tell me how many projects use the old packages. I tell you the tier for free before you buy.