|

Migración Azure Service Bus: se acaba el plazo en 2026

En pocas palabras: Microsoft retira Microsoft.Azure.ServiceBus, WindowsAzure.ServiceBus y com.microsoft.azure.servicebus (Java) el 30 de septiembre de 2026, junto con el protocolo SBMP. El reemplazo es Azure.Messaging.ServiceBus, disponible desde noviembre de 2020. Las libs viejas siguen funcionando después, pero sin soporte ni parches de seguridad.

Ponele que tenés un microservicio en .NET que factura pedidos hace cuatro años, corre con Microsoft.Azure.ServiceBus y nunca lo tocaste porque “funciona”. El 30 de septiembre de 2026 Microsoft retira esa librería, junto con WindowsAzure.ServiceBus, com.microsoft.azure.servicebus (Java) y el protocolo SBMP. La migración de Azure Service Bus hacia Azure.Messaging.ServiceBus, disponible desde noviembre de 2020, deja de ser una tarea de “cuando tengamos tiempo”.

En este artículo:

En 30 segundos

  • Fecha límite: 30 de septiembre de 2026, según el anuncio oficial de Microsoft.
  • WindowsAzure.ServiceBus usa SBMP por defecto: sin TransportType=Amqp en la connection string, deja de conectar ese día.
  • Microsoft.Azure.ServiceBus ya usa AMQP, así que sigue conectando, pero sin parches de seguridad ni soporte oficial.
  • El reemplazo es Azure.Messaging.ServiceBus, con guías de migración específicas para cada librería vieja.
  • Excepción confirmada: si usás WindowsAzure.ServiceBus solo para WCF Relay, esa parte no se retira.

Azure Service Bus es el servicio de mensajería asíncrona en la nube de Microsoft que permite desacoplar aplicaciones mediante colas y temas. La migración de Azure Service Bus significa pasar del SDK legado (Microsoft.Azure.ServiceBus, WindowsAzure.ServiceBus) al SDK moderno Azure.Messaging.ServiceBus, algo que deja de ser opcional el 30 de septiembre de 2026, cuando Microsoft retira soporte y el protocolo SBMP.

¿Qué librerías y protocolo se retiran exactamente el 30 de septiembre de 2026?

Se retiran tres paquetes de cliente y un protocolo de transporte: WindowsAzure.ServiceBus y Microsoft.Azure.ServiceBus para .NET, más com.microsoft.azure.servicebus para Java. Junto con ellos termina el soporte del protocolo SBMP, según confirma la FAQ oficial de Service Bus en Microsoft Learn: “ya no podrás usar este protocolo después del 30 de septiembre de 2026”.

El reemplazo, Azure.Messaging.ServiceBus, no es una novedad de último momento. Está disponible desde noviembre de 2020, así que Microsoft dio casi seis años de ventana. Lo cual también significa que si todavía no migraste, no es porque faltó tiempo. Lo explicamos a fondo en conectarte por SSH a tus VMs de Azure.

¿Retirado significa que deja de funcionar? La diferencia entre WindowsAzure.ServiceBus y Microsoft.Azure.ServiceBus

No, “retirado” no es sinónimo de “apagado” para las dos librerías por igual. Acá hay dos situaciones bien distintas según qué paquete uses y qué transporte esté configurado, y conviene no mezclarlas.

WindowsAzure.ServiceBus, en su configuración por defecto, sí corta. Ese paquete habla con Service Bus por SBMP salvo que la connection string tenga TransportType=Amqp explícito. Hay un parche documentado: agregar ese parámetro hace que la misma librería use AMQP 1.0 en vez de SBMP. Pero (spoiler: no es gratis) trae efectos secundarios según la guía técnica que recopiló los cambios de comportamiento: OperationTimeout se ignora, Receive(TimeSpan.Zero) pasa a ser un receive de 10 segundos, y solo el receptor que recibió el mensaje puede completarlo por lock token. Tratalo como para ganar unas semanas, no como la migración en sí.

Microsoft.Azure.ServiceBus ya usa AMQP (o AMQP sobre WebSockets), así que en el wire no cambia nada el 1 de octubre. Lo que cambia es que no vas a recibir más fixes, ni siquiera de seguridad. Está oficialmente deprecado desde hace tiempo, según el propio repositorio del SDK de Azure para .NET.

Ahora bien, hay una excepción que se pasa por alto. Si usás WindowsAzure.ServiceBus para Azure WCF Relay (NetTcpRelayBinding y afines), ese uso queda afuera de este retiro. Personal de Microsoft confirmó en Q&A que el paquete “no está deprecado para uso con Relay” y va a seguir soportado hasta nuevo aviso. Si en tu proyecto la misma librería sirve para relay y para colas, solo tenés que migrar la parte de mensajería.

Cómo migrar a Azure.Messaging.ServiceBus: mapa de tipos y cambios de comportamiento

La migración pasa por reemplazar cada cliente viejo por ServiceBusClient, que es el punto de entrada único desde el que se crean senders, receivers y processors. Cualquiera que haya usado QueueClient o MessagingFactory se topó con la dispersión de clientes: acá se resuelve con uno solo por app, compartiendo una conexión AMQP. Relacionado: certificarte en Microsoft Azure según tu rol.

Librería anteriorAzure.Messaging.ServiceBus
QueueClient, TopicClient, MessageSenderServiceBusClient.CreateSender() → ServiceBusSender
MessageReceiver, QueueClient.ReceiveAsyncServiceBusClient.CreateReceiver() → ServiceBusReceiver
RegisterMessageHandler + MessageHandlerOptionsServiceBusProcessor + ServiceBusProcessorOptions
Message / BrokeredMessageServiceBusMessage (enviar) / ServiceBusReceivedMessage (recibir)
UserProperties / PropertiesApplicationProperties
ManagementClient / NamespaceManagerServiceBusAdministrationClient
migración azure service bus diagrama explicativo

Renombrar tipos es la mitad fácil. Lo que rompe en producción son los cambios de comportamiento que compilan sin drama:

  • El settlement se movió del mensaje al receiver. Antes llamabas CompleteAsync directo sobre el BrokeredMessage; ahora esos métodos viven en ServiceBusReceiver o en los argumentos del evento del processor.
  • Auto-complete viene activado por defecto. El processor completa el mensaje solo si tu handler termina sin excepción, salvo que pongas AutoCompleteMessages = false explícito.
  • La renovación de lock tiene techo de 5 minutos. MaxAutoLockRenewalDuration por defecto es 5 minutos; un handler más lento pierde el lock y el mensaje vuelve a entregarse con DeliveryCount más alto.
  • MessageId ya no se genera solo. BrokeredMessage le asignaba un GUID automático; ServiceBusMessage lo deja vacío. Si dependés de detección de duplicados, seteá un valor estable de tu dominio.
  • El body es BinaryData, sin GetBody<T>(). Los mensajes viejos serializados con DataContractSerializer siguen circulando en las colas hasta que las vacíes; conviene que el receiver nuevo sepa leer ambos formatos mientras convive con el código viejo.

Subís el código nuevo, lo probás en local, funciona bárbaro, lo mandás a producción y de repente empiezan a aparecer mensajes duplicados en el dead-letter porque el handler tardaba 6 minutos y el lock se renovaba solo hasta el minuto 5, nadie lo había medido antes de este cambio.

¿Cómo afecta este retiro a Azure Functions con el binding de Service Bus?

Si usás el trigger o el binding de salida de Service Bus en Functions, lo que importa es la versión de la extensión, no el SDK directo. La extensión 4.x exponía tipos de Microsoft.Azure.ServiceBus y ya está retirada desde el 31 de marzo de 2025. La extensión 5.x está construida sobre Azure.Messaging.ServiceBus, con ServiceBusReceivedMessage y settlement vía ServiceBusMessageActions. Para más detalles técnicos, mirá nuestra comparativa entre Microsoft y GitHub.

Las versiones recomendadas son Microsoft.Azure.WebJobs.Extensions.ServiceBus 5.13.4 o superior para el modelo in-process, y Microsoft.Azure.Functions.Worker.Extensions.ServiceBus 5.14.1 o superior para el isolated worker. El host.json también cambia de forma: los bloques anidados messageHandlerOptions y sessionHandlerOptions pasan a ser propiedades planas bajo serviceBus. Ojo con esto: el default de maxConcurrentSessions baja de 2000 en la 4.x a 8 en la 5.x, algo que cambia el throughput de colas con sesiones si nunca lo seteaste a mano.

Y si tu function app todavía corre en modelo in-process, esa opción llega a fin de soporte el 10 de noviembre de 2026. Tiene sentido planear las dos migraciones juntas: extensión 5.x más isolated worker. Si además administrás vos mismo los servidores o VPS donde corren esos workers, opciones como donweb.com sirven para tener infraestructura en la región sin depender de un único proveedor cloud.

Checklist para llegar a tiempo antes del 30 de septiembre de 2026

El checklist que sugiere el análisis técnico del retiro arranca por inventariar, no por codear.

  • Listá todos los proyectos que referencian WindowsAzure.ServiceBus o Microsoft.Azure.ServiceBus, incluidas librerías compartidas y extensiones de Functions por debajo de 5.x.
  • Separá WCF Relay de mensajería. Para cada referencia a WindowsAzure.ServiceBus, anotá si es para colas/temas, para relay o ambas cosas.
  • Detectá connection strings sin TransportType=Amqp. Eso te dice qué está corriendo sobre SBMP hoy.
  • Agregá Azure.Messaging.ServiceBus y armá un único ServiceBusClient como singleton por app.
  • Reemplazá senders, receivers y handlers siguiendo el mapa de tipos, y probá la convivencia de formatos de mensaje viejo y nuevo en las mismas colas antes de apagar el código legado.

Errores comunes al migrar

  • Confiar en el parche AMQP como solución definitiva: agregar ;TransportType=Amqp a WindowsAzure.ServiceBus evita el corte de SBMP, pero no te saca de una librería sin soporte ni actualizaciones de seguridad.
  • Asumir que MessageId sigue siendo automático: si tu detección de duplicados dependía del GUID que generaba BrokeredMessage, con ServiceBusMessage tenés que setearlo vos mismo con un valor de negocio estable.
  • No revisar el default de auto-complete: pasar de un handler manual a ServiceBusProcessor sin fijar AutoCompleteMessages = false hace que mensajes se completen o se abandonen sin que lo decidas explícitamente.
  • Migrar el código sin drenar las colas: mensajes viejos serializados con DataContractSerializer pueden quedar ilegibles para un receiver que solo espera JSON.

Preguntas Frecuentes

¿Qué pasa si no migro antes del 30 de septiembre de 2026?

Si usás WindowsAzure.ServiceBus sobre SBMP, tu app deja de poder conectarse ese día. Si usás Microsoft.Azure.ServiceBus, sigue conectando porque ya usa AMQP, pero no vas a recibir más actualizaciones ni parches de seguridad de Microsoft.

¿WindowsAzure.ServiceBus deja de funcionar por completo?

No en todos los casos. Si lo usás para WCF Relay, Microsoft confirmó en Q&A que ese uso sigue soportado sin fecha de corte. Si lo usás para colas o temas sobre SBMP sin el parámetro TransportType=Amqp, ahí sí deja de conectar. Ya lo cubrimos antes en desplegar Microsoft Fabric con un service principal.

¿Cómo migro de Microsoft.Azure.ServiceBus a Azure.Messaging.ServiceBus?

Reemplazás QueueClient/MessageSender por un ServiceBusClient único desde el que creás ServiceBusSender y ServiceBusReceiver o ServiceBusProcessor, siguiendo la guía oficial de migración en el repositorio del SDK de Azure para .NET.

¿El protocolo SBMP sigue funcionando después del retiro?

No. Microsoft confirma en su FAQ oficial que “ya no podrás usar este protocolo después del 30 de septiembre de 2026”, así que cualquier conexión que dependa de SBMP necesita pasar a AMQP antes de esa fecha.

¿Esto afecta a Azure Functions con Service Bus?

Sí, si usás la extensión 4.x o anterior, que está basada en Microsoft.Azure.ServiceBus y ya fue retirada el 31 de marzo de 2025. Necesitás pasar a la extensión 5.x (5.13.4+ in-process, 5.14.1+ isolated), que está construida sobre Azure.Messaging.ServiceBus.

Conclusión

Lo que cambia el 30 de septiembre de 2026 no es solo un nombre de paquete, es el transporte que usa tu app para hablar con Service Bus. La migración de Azure Service Bus a Azure.Messaging.ServiceBus viene con seis años de anticipación y una guía oficial punto por punto, así que la excusa de “no hubo tiempo” no aplica.

Lo que sí conviene hacer ahora: inventariar qué proyectos usan las librerías viejas, separar el uso de WCF Relay (que no se retira) del uso de mensajería (que sí), y probar en un entorno de staging cómo se comportan los defaults nuevos, sobre todo el techo de 5 minutos en la renovación de lock y el auto-complete activado. Ninguno de esos dos rompe la compilación. Los dos rompen producción si no los revisás a mano.

Fuentes

Te puede interesar...