Transport Migration, Router.Migrator

I have a problem with NServicebus.Router.Migratior.
I am sure I am missing something.

First of all, we need to migrate our system from our RabbitMQ to RabbitMQ on Amazon MQ without loosing messages. We have around 100 microservices which publish/subscribes and send/receive messages.

Now I am looking into Migrator. I am using sample from github repository, but with mine transports. For now there are two Rabbits on different servers.
But I faced with a problem with publish/subscribe. For example, if I turn on migration mode only in one project, and this project publish (not send) event, another subscribers don’t receive it. And as I can see from RabbitMQ, this event goes only in new Rabbit exchange, and of course couldn’t be catched any subscriber on old Rabbit MQ.

I will tag @SzymonPobiega, I am sure you know much more about it :slight_smile:

And of course, if you have any ideas, maybe I am going the wrong way, and should use some another approach, let me know, please.

Thank you for help!

The Router is a community project. We also have the new supported Bridge. Could that work for you?

@ivanh Like Ramon said, we now have the Bridge. It’s in preview, which means if we need to update anything, we might break the API. But other than that, it’s fully supported.

Instead of changing every microservice, you set up the Bridge and it just works. It mimics all migrated microservices on one end, like if they’re still existing. And fully supports publish/subscribe, replying and everything. Your microservices don’t even know which other microservice does or doesn’t exist on their side. It just works™ :wink:

If you would like more info, don’t hesitate to contact us for further questions.


The Migrator was designed to be used between MSMQ and SQL Server transports. It is likely that it will not work.

As @ramonsmits and @Dennis suggested, you can now use the Bridge which is an officially supported tool if you need to communicate between two different transports (or two instances of the same transport, as in your case).

I think in your case the following approach would work:

Step 1

Create input queue for all 100 services in the new broker. Also create the same exchange topology in the new broker as in the old broker.

These queues and exchanges will be used as soon as you start migrating services. A migrated service will use the exchanges to route events to correct queues and from there the bridge will deiver them to the not-yet-migrated destinations.

Step 2

Set up the bridge to forward messages from each of these 100 queues in the new instance to corresponding queues in the old instance - by using HasEndpoint API of the bridge. Afer this is done you have a bunch of “shadow queues” in the new instance for which the bridge forwards messages to the old instance but they are not yet used

Step 3

For each microservice you need to do the following

  • Move the HasEndpoint call for this service to the new broker transport object in the bridge configuration. This will invert the forwarding allowing the not-yet-migrated endpoint to talk to the one we have just migrated. Now messages are flowing from the old to the new broker for this service.
  • Once the queue in the old broker is empty, stop the service
  • Configure the service to use the new broker
  • Start the service

I hope I didn’t miss anything. It might be a good idea to open a support case to discuss the details.