TL;DR: Azure Service Bus can run an old and a new delivery path side by side while you migrate one event stream at a time. A delivery path is the route from a publisher, through a topic and subscription, to a consuming service. Create the new path before removing the old one, because duplicate delivery is easier to survive than message loss.
This post is part of a short series on Azure Service Bus topology under load. The earlier posts explain filters, shared-topic contention, and failure boundaries. This one focuses on moving from one topology shape to another without a big-bang cutover.
The transition is the scariest part of changing a messaging topology. A publisher sends events; a subscriber consumes them. An endpoint here means a service or process that publishes or consumes messages, and an event stream means the messages for one event type. Existing publishers and subscribers keep running while services deploy on different schedules, sometimes under different teams. The system cannot stop just because the routing model changed.
Moving one event path at a time turns a topology change from a release weekend into a sequence of smaller decisions.
The safe order is simple: create the new delivery path before removing the old one. During a topology migration, duplicate delivery is usually easier to survive than message loss.
The problem with broker topology changes
Application databases have transactions. Broker configuration changes are separate operations. Creating a topic, adding a subscription, changing a forwarding rule, and removing an old rule each happen on their own. If a deployment fails halfway through, the broker does not automatically restore the previous topology.
A migration plan should account for interrupted configuration steps and overlapping application versions. Some endpoints will support the new topology before others do.
If something goes wrong, duplicate delivery is usually easier to handle than lost events. Idempotent handlers, Service Bus duplicate detection, and outbox-style patterns can help with duplicates. Lost events are harder to explain.
Start with compatibility mode
A safe migration starts by deploying software that understands both topologies. Every endpoint involved in the migration can then use either the old or new route for a given event without moving all events immediately.
For example, a system might start with all events still using the existing shared-topic-and-filter path. The new topology is present in the code, but every event is explicitly mapped to the old path. That sounds boring, which is exactly what you want from the first deployment. The first deployment proves compatibility without changing delivery behavior.
Once that version is running everywhere that matters for a selected event, the team can move that event’s subscribers and publishers independently.
Move subscribers first
For an event such as InvoiceIssued, the first meaningful step is to create the new subscriptions. The subscribers are configured to listen through the new event-specific topic, but publishers can keep publishing through the old path for now.
At this stage, the event may still arrive through the old subscription rule. That is acceptable. The goal is to make sure the new path exists and is ready before any publisher depends on it.
If automatic subscription creation is disabled because the endpoint does not have permission to manage Service Bus entities, deployment tooling can perform the same step. Prepare subscribers before publishers switch.
Then move publishers
After the subscribers for InvoiceIssued are ready, publishers can switch that event to the new topic. Other events stay on the old path. That keeps the migration narrow. If something behaves unexpectedly, the rollback discussion is about one event stream, not the whole system.
Event selection matters here. A team might exercise the process with a low-risk event or choose a high-volume event to get early performance benefits. The topology lets the team make that choice deliberately.
Use forwarding as a temporary bridge
Azure Service Bus autoforwarding can help during awkward transition periods. The official docs describe it as chaining a queue or subscription to another queue or topic in the same namespace. When enabled, Service Bus automatically removes messages placed in the source entity and puts them in the destination entity. If some publishers cannot be upgraded yet, a subscription on the old shared topic can forward matching events to the new event topic.
Use the bridge only for the migration. Forwarding adds broker work. Standard charges an operation for each forwarded message; Premium includes that work in the capacity of the allocated Messaging Units. Azure Service Bus also limits an autoforwarding chain to four hops, with each entity in the chain counting as one hop. Messages sent into a chain that exceeds that limit are dead-lettered. Remove the bridge when the migration is complete.
If some subscribers cannot be upgraded yet, a temporary bridge can forward events from the new event topic back toward the old shared path. That bridge needs careful naming and monitoring, because it can otherwise hide loops, duplicate delivery, or forgotten migration infrastructure.
| Migration step | Goal |
|---|---|
| Deploy compatibility-capable endpoints | Prepare software without changing routing behavior |
| Create new subscriptions for one event | Make the new delivery path ready before publishers use it |
| Switch publishers for that event | Move one event stream to the new topology |
| Remove old rules for that event | Clean up after the new path is proven |
Clean up last
The final step is decommissioning the old rule or subscription for the migrated event. This should happen after the new path is observed under real traffic. Removing the old path too early is where migrations become risky.
Cleanup should also include the dead-letter queues on temporary forwarding sources. The autoforwarding documentation calls out that if the destination entity fills up, is disabled, or has transient forwarding failures, the source entity can dead-letter messages until the destination has space again or is re-enabled. See the dead-letter queue documentation for the recovery and inspection model.
A migration bridge is only safe if it is monitored like production infrastructure.
Leaving both paths in place for too long can create duplicate delivery, extra broker work, confusing dashboards, and higher operational cost. The migration finishes when the temporary path is gone.
Move one event stream at a time
The migration plan is part of the architecture. Move one event stream while the rest of the system keeps using the existing path. Services can deploy on their own schedules.
Azure Service Bus provides the pieces for this approach: topics, subscriptions, filters, forwarding, and deployment tooling. Use them in this order: build the new path, observe it, move publishers, and clean up the old path. Repeat for the next event stream.
Further reading:
- Azure Service Bus autoforwarding
- Azure Service Bus duplicate detection
- Azure Service Bus dead-letter queues
- Azure Service Bus quotas
- Previous post: Designing for blast radius
Common questions
Before running an Azure Service Bus topology migration, I would start with these questions.
Why prefer duplicates over loss?
Because duplicates can often be handled with idempotent processing or deduplication. A lost event may have no reliable recovery path unless the publisher can replay it.
Should forwarding be part of the final topology?
Sometimes forwarding is the right long-term tool, but migration forwarding should be treated as temporary unless the final design explicitly depends on it.
What should I remember?
Topology migrations are safest when each event stream can move independently.
