Hi @akg17,
That’s a lot of info. In general the Solace binder supports the “Persistent Publish-Subscribe” and the “Consumer Group” patterns as defined by the Cloud Stream framework, so assuming you don’t have any logic in your apps that was written specifically for Rabbit or Kafka the migration should be pretty smooth.
I would start off by looking at the docs for the Solace Cloud Stream Binder here. Among other things, this page covers initial information around message headers, dynamic routing (StreamBridge or TARGET_DESTINATION headers), Failed Consumer Message Error Handling (Internal Solace DLQ, but also an Error Queue) as well as Consumer Concurrency which should tackle your parallelism approach.
As far as your question around “Exchange Type support” in Solace I we don’t have the concept of an “Exchange”. In Solace a message is published to a topic (which is really just metadata on the message) and these topics can be subscribed to by Endpoints, usually a Queue Endpoint which holds those messages to be consumed. I would highly recommend reading up on Solace Topics and Queues in our docs (maybe start with Core Concepts) and/or checking out @Aaron’s video here. It is important to spend the time to understand topics and how Solace dynamically routes them to get the most value out of your EDA in the long run so don’t skip this part 
For “Request mechanism for Queue creation in solace” the Cloud Stream binder will automatically try to create the queue and apply the topic subscriptions by default. This is great in a development environment, but in pre-prod or production environments teams usually use SEMPv2 which is our RESTful management API to create the queues ahead of time. The binder then has flags (such as provisionDurableQueue) to tell the Cloud Stream apps to not try to re-create them.
I would also check out our Cloud Stream Samples in this repo.
That’s a lot of info to get started but go ahead and dig in and let us know where you need help.